ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

機械学習の分野でも注目される、メタモルフィックテスティングとは何か。

 先日のJEITAのイベントで、メタモルフィックテスティング(Metamorphic Testing、MT)というものを知り、「誰かMetamorphic Testingの勉強会やりませんか?」とブログに書いたところ、ソフトウェアテスト・ヒストリアンの辰巳さんが資料をたくさん紹介してくださいました。ちなみに、一緒に勉強してくれる人は誰もいませんでした。

www.kzsuzuki.com

 ICSE MET'2017のサイトにも、MTについてのスライドがたくさん掲載されていたので、学んだところを紹介してみたいと思います。
 日本語の論文も無償で見られるものがいくつかあるのですが、どちらかといえばMTについての知識は前提として、それを機械学習にも応用してみたという内容なので、基本を学ぶには敷居が高そうです(論文だから当たり前か・・・)。

メタモルフィックテスティングの概要

 まず、Chris Murphy氏の『Applications of Metamorphic Testing』(ppt)が一番わかりやすいです。スライド終盤のサマリには、以下のようにあります。

  • MTは、既存のテストケースから新しいテストケースを生成する手法である。
  • テストオラクルのないアプリケーションにおいて、バグ検出の役に立つことがある。
  • ソフトウェアのメタモルフィックプロパティ(metamorphic property)に強く依存する。
  •  一つずつ、見ていきましょう。

    なぜテストケースを増やす必要があるのか。

     「新しいテストケースを生成する」理由は何でしょう。
     境界値分析や組み合わせテストといったテスト技法は、テスト空間を論理的に絞り込み、効率的にテストケースを減らすための技術でした。なぜあえて、テストケースを増やすのか。
     このスライドでは「だって、テストケースは多ければ多いほどいいだろう?」とあります。手動テスト中心のテスターが聞くと吐血しそうな意見ですね。

     たとえばこちらのICSTの論文『Metamorphic Model-based Testing of Autonomous Systems』(pdf)では、ドローンの飛行や障害物回避のシミュレーションプログラムにMTを応用した例が載っています。ドローンの出発地点と到着地点、その経路にある障害物には無数のパターンがあるので、ある特徴的なテストケースをいくつか通すだけでなく、そこから大量のテストケースを派生させて、プログラムの妥当性を検証することが有効なのですね。

    テストオラクルってなんだっけ?

     テストオラクル(Test Oracle)などという用語を使うのは、I/JSTQBで学んだ界隈の人だけだと思っていましたが、MTの文脈では当然のように使われている言葉です。
     ISTQB用語集に追加された日本語検索機能をさっそく使ってみましょう! 使い方は、湯本さんのnoteから!

    note.mu

    テストオラクル(test oracle)
    テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する(ベンチマーク用の)システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。

     テストオラクルがないというのはつまり、「どういう出力なら正しいのか」がよくわからない状況ということですね。

    メタモルフィックプロパティとは?

     「メタモルフィックプロパティ」(Metamorphic Properties)とは一言でいうと、対象とするソフトウェアが備えている「性質」のことです*1。MTでは、この性質から多くのテストケースを導出することを目的としています。

     それってプログラムの仕様そのもの、あるいはそれを変換した高位レベルテストケースのことでは、とも思いませんか? 一般的なテスト技法でテストケースの絞り込みを行わなければ、テストケースはいくらでも追加できそうなものです。
     たとえば、「12歳以上は料金1,000円」という仕様からは、入力である年齢を12歳、13歳、14歳、・・・とし、出力が「1,000円」となることを確認するテストケースがどんどん作れます。

     ですが、メタモルフィックプロパティはもっと別のものです。
     わたしは、「プログラムの仕様として定義するまでもない、自明な性質」と解釈しています。

    メタモルフィックプロパティの具体例

    数値リストから最小値を求めるプログラム

     抽象的な話になってきたので、先の資料から具体例を引用します。
     整数のリストの中から最小値を得る関数 findMinを、以下のように書くとします(バグがあります)。

     「2、1、4、3」というリストを入力にすると、期待値(つまり最小値)は「1」になる、というテストケースは、以下のように表現することができます。

    { {2, 1, 4, 3}, 1}

     さて、このプログラムが持つべきメタモルフィックプロパティには、どういうものが考えられるでしょうか。
     それはたとえば、「リスト内の数字を並び替えても、出力値(最小値)は同じになる」という性質です。このような性質は、おそらく外部仕様として明示されない、「自明な」性質ということができるでしょう。

     この性質に従ってテストケースを生成すると、

    { {4, 2, 3, 1}, 1}

    というテストケースが通らないことがわかり、バグを検出することができます。

    形式的な表現をしてみると

     少し形式的に表現してみましょう。
     プログラムfに対する元のテストケースを {x, f(x)} と表現します。

     元のテストケースの入力値を関数tに通すと、新しい入力値はt(x)、プログラムfからの出力値はf(t(x))となります。
     一方、元のテストケースの出力値を関数gに通すと、新しい出力値はg(f(x)) となります。
     プログラムfのメタモルフィックプロパティとは、すべての入力値xに対して、f(t(x))=g(f(x))を満たすような関数ペア(t, g)のこと。文字列だと全然わからないですね・・・。

     先のfindMinの例では、関数tは「リスト要素の並び替え」に相当します。出力値の方は変わらないことを期待しているので、関数gは恒等関数になるでしょう。入力に「リスト要素の並び替え」という操作を行っても、出力値は変わらないというのが、findMinのメタモルフィックプロパティです。

    一般的にはどんなプロパティがある?

     一般的に、どんなメタモルフィックプロパティがあるのでしょうか。P.22からその例が書かれています。
     元のテストケースが「要素a~fの総計がsになる」というものだったとして、

  • Permute: 並び替えを行っても総計はsと変わらない
  • Add: 各要素に定数を足すと、総計は s+定数*6 になる
  • Multiply: 各要素に定数を乗じると、総計は s*定数 になる
  • といったものがメタモルフィックプロパティとなります。これはだいぶ単純というか・・・数学以外には適用できそうにない、退屈な性質ですよね・・・。
     もう少し違うタイプとして、以下のようなものが紹介されています。

  • Noise-based: 出力に提供を与えないであろう入力(の変化)
  • Semantically Equivalent: 意味的に「同じ」入力。
  • Heuristic: 元に「近い」入力。
  • Statistical: 統計的に同じ性質を示す入力。
  • 数値計算分野以外での応用

     メタモルフィックプロパティが上で紹介したようなものばかりだと、MTは数値計算関連のプログラムにしか応用できないのではと思いますが、Zhi Quan Zhouさんの講演『Metamorphic Testing: Beyond Testing Numerical Computations』(pdf)によると、数値計算関連分野での適用は全体の4%でしかないそうです*2

     この講演で紹介された適用例は、プログラム難読化ツール*3
     難読化ツールのメタモルフィックプロパティには、たとえば以下のようなものがあります。

  • 同じソースコードを入力するといつでも、動作的に等価なプログラムが出力される。
  • 一つのソースコードに対し繰り返し難読化を何度かけても、動作的に等価なプログラムが出力される。
  •  こういったプロパティを利用して、一般的なテストでは必ずしも検出できないバグが、MTであれば検出できるという例を示しています。

     また、オンライン検索での例も紹介されています。一口にオンライン検索といっても、GoogleのようなWebサイトの検索、ホテルや飛行機の空き状況、商品、用語、地図など無数にありますが、これらに共通して言えそうなメタモルフィックプロパティがあります。

     まず一般的な(general)メタモルフィックプロパティとして、以下が考えられます。

    「AがBに包含されている」という関係が成立しているなら、
  • Aの結果はBの結果の部分集合になる
  • Aの結果の数は、Bの結果の数以下になる
  •  この2つ目のプロパティから導出できる具体的な(concrete)プロパティは、たとえば店舗検索において、

    検索する地域を絞ることで、ヒットする結果は絞る前より少なくなる

    というものが考えられます。このメタモルフィックプロパティを利用してテストケースを生成し、妥当性を確認することができます。

    まとめ

     引用した資料に明確に書かれているわけではないのですが、生成されるテストケースが常に「期待値付き」であることが非常に重要だと思います。いくら大量にテストケースを生成したとしても、それが期待値なしであればあまり役に立ちませんし、自動化もできません。

     テスト技法といえば、テストケースを合理的に選択することと思いがちでしたが、「とにかくたくさんのテストパターンが欲しい」「でもテストオラクルがない・・・」という状況において、有効だが数が少ないテストケースから、期待値付きのテストケースを大量に派生させる技術として、メタモルフィックテスティングが有望な技術だということがわかりました。

    *1:他の資料では、「メタモルフィック関係」(Metamorphic Relations、MR)という用語も出てきますが、どうやら同じものを指しているようです。

    *2:Chris Murphyさんの資料では、実際の応用分野として、生物情報学、機械学習、ネットワークシミュレーション、コンピュータグラフィックスなどがあるとのこと

    *3:クラッカーなどに重要なシステムの内部情報を与えることを防ぐためのプログラム。obfuscator。

    「ソフトウェアエンジニアリング技術ワークショップ2017 ~人工知能ブームの中でのソフトウェアエンジニアリング~」に参加

     2017年12月15日(金)に、JEITA(一般社団法人 電子情報技術産業協会)の「ソフトウェアエンジニアリング技術ワークショップ2017」に参加してきました。プログラムなどはこちらをご覧ください。
     テーマは「人工知能ブームの中でのソフトウェアエンジニアリング」。とても勉強になった催しでしたので、許される(であろう)範囲でシェアしたいと思います。

     なお、わたしはディープラーニング初学レベル以下です(堂々)。講演者の方のご発言の趣旨を正しく理解できず、間違った要約をしてしまっているかもしれません。申し訳ありませんが、その際はご指摘いただければ修正・削除いたします。

    基調講演: 機械学習工学に向けて

     株式会社Preferred Networksの丸山宏さんの基調講演では、機械学習の概要や潮流について、幅広くお話しいただきました。どちらかといえば、機械学習のすばらしさよりも、限界や注意点に重点を置かれているように感じました。

    ディープラーニングが合うもの合わないもの

     演繹的な「モデルベース開発」と、帰納的な「モデルフリー開発」、という言葉がありました。
     銀行のトランザクションにように、人間が定義したルールに従って動くシステムは前者。複雑すぎてルールが書き下せないようなものに後者を適用とするというお話です。 後者の開発においては、十分な精度が出るかはやってみないとわからないため、Expectation Controlと、アジャイル的なアプローチ・PoCが必須との注意点もありました。

     品質の判断として、これまでは「レビュー工数」のようなプロセス指標で測定していたところを、ディープラーニングのシステムにおいてはプロダクト自体の性能(判定精度)で示せるのが大きな違い、とのお話がありました。ただ個人的には、「正確に判定できる」というのは品質特性の1つでしかないので、それだけとって「品質を定量的に示せる」とするのは物足りないと感じます。

    機械学習に基づくソフトウェアの難しさ

     技術的な難しさとして、要求定義と品質保証について言及がありました。
     要求定義の難しさは、いわゆる「フレーム問題」と呼ばれるもので、ハイコンテキスト前提の人間の指示を、ソフトウェアがパーフェクトに忖度することはできないという点です。
     品質保証の難しさは、ディープラーニングにおける「何かを変えるとすべてが変わってしまう」(Changing Anything Changes Everything)性質に由来するものです。この性質のもとでは、ユニットテストを定義することさえ困難であるということです。また、adversarial exampleのような新しいタイプの脆弱性が生まれていることも、保証の難しさにつながります。

     またビジネス面の難しさとして、「100%のものはできない」ということに対する社会的な受容が必要ということです。同様の話は、SQiP2016における、デンソーの早川浩史氏のご講演「つながるクルマのセーフティ&セキュリティ」でもあったと記憶しています。そもそも現在のソフトウェアだって完璧なものではないことは明らかなのですが、「ディープラーニング/自動運転車は判定を間違うこともある」ことを社会が受け入れ(あるいは麻痺し)なくてはなりません。

    統計を勉強しよう

     ソフトウェアエンジニアに必要な知識として統計、特に事前確率などベイズ統計の基本的な知識を挙げていました。
     質疑応答では、ソフト屋は統計を知らないといった論調があったように思いますが、割とみなさん統計好きですよね? 僕はそうでもありませんが・・・特に自由d・・・うっ頭が・・・。

    所感

     機械学習のニュースやトレンドをきちんと追っている人には当たり前のお話だったのかもしれませんが、特徴や注意点などの概要をお聞きすることができて有益でした。また、今後テストがますます難しくなっていくことがよくわかりました。
     こんな話もありましたね・・・これも、Changing Anything Changes Everythingの一種だと思います。

    itpro.nikkeibp.co.jp

    AIによるソースコードレビューの変革

     富士通アプリケーションズ株式会社の森崎雅稔さんによる、「AIでソースコードの良しあしを判定する」お話です。Twitterでも話題になりましたね。ニュース記事はコチラ。

    itpro.nikkeibp.co.jp

    何をやっているのか

     記事を読んだだけでは、従来のソースコード解析との違いがよくわからなかったのですが、かなり別ものでした。この技術ではコードの文法や意味を理解させるのではなく、コードを画像のパターンとして認識させて、良い/悪いの判定を行っているのだそうです。
     ここでの判定は「バグの有無」ではなく、保守性や可読性といった内部品質の良しあしです。ただ経験則的に、内部品質が悪いコードを書く人は、バグを作り込むことも多いという相関があり、悪い判定はそうズレないとのことでした。

     なお、単純に画像化するだけでなく、レビューエキスパートの観点が反映される工夫をしています。
     たとえば、いわゆる「複雑度」といえばネストの深さなどで計算されますが、そういう制御構造以外にもレビュアが「複雑でレビューしづらい」と感じるコードの特徴があるので、そういう特徴がうまく画像パターンに現れるようにしているということです。
     ディープラーニングといえば、学習用の加工だけして後は機械に学習させるというイメージを持っていたので、これは意外でした。

    運用面での工夫・苦労

     今回紹介された技術は、少なくとも現時点では既存のコード解析ツールを代替するものではなく、互いに補完するものとしています。既存のツールに加え、今回のツールをSEの日常に自然に組み込んでいくことが大事だとのお話がありました。また、既存のツールのように「ダメな点をひたすら指摘する」のではなく、良い部分は良いと見える化することが、ユーザのモチベーションにもつながると。

     その他、「いいコード」「悪いコード」の収集と、それらのスコアリング(もちろんレビュアによる手動!)に苦労されたとのこと。これは想像に難くないですね・・・。

    所感

     どんどん大量のデータが集まってくるセンサーデータと違って、人間の手による成果物をディープラーニングの入力にするのは厳しそうだと思います。特に教師あり。こんな話もありました・・・。

    itpro.nikkeibp.co.jp

    ソフトウェアの不具合検知・修正への機械学習の応用について

     産業技術総合研究所の森彰さんのお話です。
     「AIによるソースコードレビューの変革」とこちらが、「AI for SE」のカテゴリです。

    AIで何ができるのか

     Fault Detection、Fault Localization、Fault Repairの、3つの分野での応用を紹介されています。検知、同定、修復、ですね。
     重点が置かれていたのは、修復です。
     方法の1つとしては、バグを含んだソースコードの一部を変換し、そのコードでテストを実行するというもの。テストをパスすればスコアが得られるゲームとして、変換を繰り返し行っていくうちに、ものによっては修復ができてしまうそうです。この場合の「修復」は、「既存のテストをすべてパスする」という意味でしかなく、単にテストが弱かったということもあるのですが、それを踏まえても3~4%は「本当に」直るとのこと。

     これも十分、力業という印象を受けたのですが、さらに力づく感があるのが、Vertical Code Transplantingという技術。ある特定の機能を実現するためのコードは、似たものがきっと世界中のどこかのリポジトリにあるだろうということで、それを探してもってきて、それを自分のコードに反映してしまうのだそうです。この「似たもの」というのは、文法構造の類似ではなく、やろうとしていることが似ていなければならないのですが、この「意味的コードクローン」の判定がそれなりにできてしまうので、荒唐無稽な話でもないようなのです。
     自動的にコードが修復されていく世界が未来過ぎたのですが、「GenProg」で検索すると関連資料がたくさんあり、驚きました。

    質問したこと

     今回のお話で気になったのは、ユニットテストが完備されていて、かつ短時間で完了できるということが前提になっている点です。
     たとえばIoTの世界だと、多数の機器が接続された、バリエーション多彩な環境で動作して初めて発現するバグがより深刻だと考えられます。そのようなバグを見つけるにはシステムテストレベルのテストが必要で、その実行はおそらくユニットテストのような時間オーダーでは終わらないのでは・・・という点が疑問で、質問させていただきました。

     そのようなケースは、修復よりまず検知と同定が課題であり、AIによるログのパターン解析が使えるだろうとのご回答をいただきました。
     また上述のような背景から、今後はプロダクトコードよりもテストコードを正確に書くことが重要になってくるとのご意見もいただきました。

    所感

     このような話を弊社の大先輩エンジニアとしたところ、「テストコードを完璧に書くというアプローチと、要件を形式的に書くというアプローチの本質的な違いは何なのか、意見を聞きたい」と言われました。

     テストコードをプロダクトコードに対する要件と捉えると、本質的な違いはないようも思います。
     少し考えて、「前者のアプローチは、適切なテストコードが追加されるごとに、自動的に品質が良くなる(蓋然性が高い)点が違うのでは」といった趣旨の回答をしましたが、それは後者でも変わらないですね。つまり、不足していた仕様を追加すれば、そこから導出されるソフトウェアの品質は上がっているはずなので。

     もう1点、形式的に記述された仕様から導出するプログラムが仕様を完全に満たすのに対して、テストコードから修復されるプログラムはあくまで「いろんな可能性の中で一番よくテストコードをパスしそうなもの」であるにすぎず、すべてのテストコードをパスすることを保証しない(もっとも多くパスすることも保証しない)という点が違うのかなーと思いました。
     みなさんはどう思われますか?(全然所感じゃない)

    Neural Network ConsoleによるDeep Learning研究開発の効率化

     ソニーの小林由幸さんによる、ソニー謹製のディープラーニング研究開発ツールのお話で、ここから2つが「SE for AI」のカテゴリー。  プログラマ向けの関数プログラムである「ライブラリ」と、商用開発に対応したツールである「コンソール」があり、セッションは主に後者のデモでした。
     自社ツールの紹介ではありますが、お金のにおいを感じさせない、開発者の情熱に溢れたプレゼンテーションでした。

     製品紹介は、YouTube上でも見ることができます。
     こちらもディープラーニング学習者ならとっくに知っているものなのでしょうが、わたしは初見でして。
     GUI上で各種レイヤをグリグリ並べて、整形済みデータを流し込むと、すぐに学習が始まって精度も測定される。一番よい精度を出せそうなネットワーク構成の探索も自動でやってくれる。コストに効いてくる計算量もわかる。そしてそのGUIも、SONYらしく美しい。


    Neural Network Console:ツールで体験する、新しいディープラーニング

    所感

     AffineやCNNなどは、プログラミングにおけるif文と同じで、一度理解すればそれで済む。理解したら、コンソールのようなツールでいろいろ試してほしい。というお話がありました。
     わたしは『ゼロから作るDeep Learning』でゼロから学びきれず落伍しましたが、再度立ち上がって一通り基礎を習得し、そのあと堂々とこの手のツールを使えるようになりたいです。

    ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

    ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

    機械学習における品質保証のチャレンジ

     国立情報学研究所の石川冬樹さんによるセッションです。
     機械学習に基づくソフトウェアにおける困難と、その打開策についてお話いただきました。

    何が難しいのか

     欠陥に気づくことができるのか、直せるのか。何をもって完成とし、どのようにユーザに説明するのか。
     テスト工程以降のあらゆる工程に困難さが発生することになります。それを解決する方法として、いくつかの手段を紹介いただきました。

    • Metamorphic Testing: 入力をこう変えると出力はこう変わるはず、という関係を活用して多数のテストケースを生成する。たとえばアイテムのランキングの機能があったとして、アイテム群から1つのアイテムを抜いても、残ったアイテムのランキングの上下関係は変わらないはず、という関係を確認するためのテストは、たくさん考えることができる。
    • Search-based Testing: メタヒューリスティックを用いて、スコアを最大にするようにテストスイートやテストケースを生成し、カバレッジを高く、テストケース数を少なくする技法です。
      ・・・これではまったくわかりませんが、辰巳敬三さんによる記事がこちら(pdf)にあります。

     またホワイトボックステストにおいて、コードをカバーするだけではダメで、ニューロンのカバレッジを上げる必要があるとのお話がありました。とはいえこれは人手でできるものではないので、やはり機械による大量入力を回すしかない。また、GAN(Generative Adversarial Network)による意地悪なデータでソフトを試すというアプローチも実用になりそうとのことでした。

    blogs.nvidia.co.jp

    所感

     テスト技法といえば、「無限ともいえるテスト空間をいかに効率よく、合理的に狭めるか」、ざっくりいうと「テストケースをどう減らすか」に焦点を当てたものを捉えていました。
     が、「テストケースをどう増やすか」という真逆の目的をもった技法があることを学びました。短時間で完了するテストケースと期待値をできるだけ多く、自動的に生成し、それを全部流してプロダクトの妥当性を検証するというアプローチなんですね。
     誰かMetamorphic Testingの勉強会やりませんか? 理解できる自信はないのですが。

    総合討論

     5人の講演者の方と会場からの質問による、パネルディスカッションです。
     いろいろなトピックがあったのですが、特に印象に残ったのは「ディープラーニングに基づくソフトウェアが出した答えをどう説明するか」についてでした。単に「学習の結果、こうなりました」では、答えを言われた方は納得できないでしょう。

     富士通の森崎さんは、たとえば「コードが良くない」と判定された理由をできるだけ伝えるようにしているとの答えでした。やはり判定を誤ることもあるので、既存のメトリクスも使って総合的に判断しているとのこと。

     一方、ソニーの小林さんのご意見は逆で、「理解してもらう必要はない」とのこと。なぜなら、人が理由を知りたがるのは、その理由に基づいて人が対処しなくてはならないから。将来的にはその対処を機械が行うようになるので、人の介入は不要、説明も不要になるという見解です。
     森さんのお話にあった欠陥修正にしても、自動で修復されていくのであれば「コードのどこの部分が悪かったのか」を人が知る必要はなくなるのかもしれません。
     ただそうはいってもその見解に誰もが納得するわけではないので、人の意識を変革していく必要があり、それは我々の仕事だ、というご意見でした。

     石川さんのご意見は、「説明できない、ルール化できないからこそディープラーニングを使っているのだから、説明を必須とすると普及しない」というものでした。ただし、社会学的・心理学的に「説明」が必要なのであれば、ディープラーニングでそれっぽい説明を自動生成すればいい、との極論(?)も出ました。

    おわりに

     パネル含め、すべてのセッションが有意義で面白く、ディスカッションも活発で、参加できたのは本当にラッキーでした。
     JEITAさんのイベントは初めてだったのですが、今後もウォッチしていきたいと思います。ありがとうございました!

    【翻訳】「アジャイルテスト」、わたしたちの定義

     『実践アジャイルテスト』の著者である、Janet Gregory、Lisa Crispinの両氏による『Our Definition of “Agile Testing”』という記事を、許可をいただいて翻訳してみました。

    agiletester.ca

     この本、勢いで買って店晒しにしておったのですが、最近やっと読み始めまして、とても気に入っています。あらゆる経験、知識、エピソードをとにかくぶっこんでみた!という勢いと厚さが好きです。つまみ食いでも得られるものがあると思いますので、未読の方はぜひ。

    実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

    実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

     では、以下が翻訳です。

    アジャイルテスト」、わたしたちの定義

     Janetの講義で、学生の一人がアジャイルテストの定義を尋ねてきた。彼が求めていたようなわかりやすくきれいな定義は、3日間の講義の中では得られなかったのだ。
     Janetは自著である『Agile Testing』と『More Agile Testing』を調べてみたが、簡潔な定義はどちらにも載っていなかった。ブログポストにあるものが、最も答えに近いものだった。

     そこで、LinkedInのアジャイルテストのグループと、長く続いているアジャイルテストのYahooグループで質問してみることにした。
     「アジャイルテストの定義はどんなものだと思いますか?」

     多くの人が、アジャイルを定義しようとしたり、定義の中で「アジャイル」という言葉を使ったりしていた。この言葉を使うことにまったく同意しない人もいるが、「アジャイル」という言葉自体は形容詞であり、「アジャイルテスト」という言葉は間違ってはいないだろう。また、テスターのロールではなく、テストという活動自体にフォーカスしたかった。

     すべてのやり取りと、わたしたち自身の考えを踏まえた結果、考えついたのが以下の定義だ。

    アジャイルテストの定義(Lisa Crispin、Janet Gregory)
     開発の始めからデリバリーまでに行われる協働的なテストのプラクティスで、顧客にビジネス価値をもたらす高品質なプロダクトの、高頻度なデリバリーを支える。テストの活動は、欠陥を見つけることではなく抑えることにフォーカスするものであり、「品質に対するチーム全体の責任」という考え方を強め、支えるためにある。

     アジャイルテストは、以下のようなテストの活動を含む(が、これに限られない)。
     具体的な例を挙げて開発を導く。アイデアや仮定をテストするために質問を投げかける。テストを自動化する。探索的テストを行う。性能、信頼性、セキュリティといった品質特性のためにテストする。

     この定義があなたにも響いてくれればいいが、そうでなければコメントを残すか、メールしてほしい。この定義はまだ初めのもの、ドラフトであり、変更したり適応させたりすることに、わたしたちはやぶさかでない。

     すでに寄与してくれた人に感謝したい。有用なアイデアもあればそうでないものもあったが、すべてがわたしたちの検討の役に立った。
     以下は、グループメンバーからもらったコメントや定義の一部である。上述のグループを訪れて、やり取り全体を読むこともできる。

    • 重要なプロダクトを欠陥なしかつ迅速にリリースできるようにする、協働的かつ継続的な活動
    • アジャイルのコンテキストでは、高速なイテレーションと継続的な改善という環境におけるテストであり、変化とプレッシャーに対応するものである。
    • Elisabeth Hendricksonの『Agile Testing Overview』(pdf)を教えてくれた人もいた。これはみなさんにぜひ読んでもらいたいものではあるが・・・、21ページもあり、簡潔な定義とは言えない。
    • イテレーションベースの成果物を支える迅速なフィードバックをもたらすために、短い時間で結果が得られる効果的なテスティング
    • アジャイルテスティングとは、最初の1日目から、プロダクションに提供されるまでの間ずっと取り組むものである。
    • アジャイルテスティングは、ビジネス価値と、顧客が求める品質に直接フォーカスする。アジャイルテスティングにおいてテスターは、品質に対して一丸となって責任を持つ、アジャイル開発チームの一員である。
    • 顧客の視点からテストし、ビジネス価値を高めること。それはプロダクトのゴールなのだから、とても重要だ。Gojko Adzicの「ソフトウェア品質のピラミッド」の言葉を借りると、「使うことができる」(usable)、「役に立つ」(useful)、「成功である」(successful)というのは時に、テストの話だとは考えられていないが、わたしにとって「アジャイルテスター」は、これらすべてのレベルを意識しているべきであり、少なくともどのようにテストすればいいのかをチームに知らせるべきだ。
    • 品質に対するチームの責任感を強める。
    • Karen Greaves and Samantha Laingのテストマニフェストに言及する人もいた。

    わたしたちは、以下のことに価値をおく。
    「最後に行うテスト」よりも「ずっと行うテスト」に、
    バグを見つけるよりもバグを防ぐことに、
    機能をチェックすることよりも自分の理解をテストすることに、
    システムを壊すことよりも最高のシステムを作ることに、
    テスターの責任よりも品質に対するチームの責任に。

    • アジャイルテストは、アジャイルソフトウェア開発において切り離された活動ではなく、切り離せない部分である。
    • アジャイルテストは、バグが起こるのを待っているのではなく、未然に防ぐものである。
    • 協働/アジャイルは、プロジェクトの最後だけ(あるいは最初の少しと最後だけ)でなく、プロジェクト全体を通じてテスターは一緒にいるのだという事実を教えてくれる。
    • ユーザストーリーに対して質問を投げかけたり、受け入れ基準を作り上げるのを手伝ったりすることで、プロジェクトは良くなっていく。バグを見つけるのが遅くなるほど、プロジェクトにとって高くついてしまう。
    • アジャイルテスティングは、サイクルの短い開発でペースを保つためのテストである。
    • 価値とアジャイルマニフェストのプラクティスを支える、テストのプラクティス

     わたしたちが提起した問題に取り組み、探究を助けようとしてくれた、以下の方々に感謝する。誰かを漏らしていたら申し訳ありません。
     Augusto Evangelisti, Tim Western, Gaurangi (Surve) Rawat, Richard Cowling, Vivek Sharma, Wim Heemskerk, Eddy Bruin, Steven Gordon, Lionel Champalaune, George Dinwiddie, Adrian Howard。

    JSTQB Advanced Level - Test Analystシラバスのわからないところ - その1 -

     来たる2017年2月11日(土)、JSTQBの試験が催されます。わたしは、テストアナリストの第1回試験を受験するつもりです。前回のトライアルは受け忘れていました。
     受験料が高いので一発合格したいのですが、もう3週間前となってしまったため、慌ててシラバスを読み始めましたよ。61ページ中、すでに14ページまで読み終わりました。すごくないですか? ちなみに、7ページ目は「シラバスの紹介」で、本文は8ページ目からです。すごくないですか?

     さて、テストマネージャーの方は全章について2周分も学習ブログ記事を書いたのですが、もうそんな余裕はありません。シラバスを読んで、理解できなかった部分を解読するだけの記事を投下していきます。

    1.3.1 テスト計画作業

     以下のような記述があります。

    The documentation must be accurate to be effective. The Test Analyst must allocate time to verify the documentation ...
    正確で有効なドキュメントを作成する必要がある。テストアナリストは、時間をかけてドキュメントを検証する必要がある。

     これだと、テストアナリストがドキュメントを検証するかのように読めます。
     テスト計画の話なので、「ドキュメントの検証に時間を割り当てる必要がある」というのが適切ではないでしょうか。

    1.3.2 テストのモニタリングとコントロール

     以下のような記述があります。

    While the Test Manager will be concerned with compiling and reporting the summarized metric information, the Test Analyst gathers the information for each metric. Each test case that is completed, each defect report that is written, each milestone that is achieved will roll up into the overall project metrics. It is important that the information entered into the various tracking tools be as accurate as possible so the metrics reflect reality.
    テストマネージャがメトリック情報の要約を編集およびレポートする場合、テストアナリストは各メトリックの情報を収集する。完了した各テストケース、記述した各欠陥レポート、達成した各マイルストンを全体的なプロジェクトメトリクスにまとめる。さまざまな追跡ツールに入力する情報を可能な限り正確にして、メトリクスに現実を反映させることが重要である。

     この訳では、whileの意味が失われているのではないでしょうか。
     この文章は、テストマネージャーとテストアナリストを対比したものだと僕は理解しています。つまり、以下のような感じ。

    • テストマネージャー: 要約されたメトリクス情報を集めて報告することに関心がある。overall的。
    • テストアナリスト: 要約される前の個別の情報を成果に保つことに関心がある。each的。

     「全体的なプロジェクトメトリクスにまとめる」には主語がないのですが、この仕事をするのはアナリストではなくマネージャーなのではないでしょうか。

    1.5 テスト設計

     以下のような記述があります。

    Still adhering to the scope determined during test planning, the test process continues as the Test Analyst designs the tests which will be implemented and executed.
    テスト計画作業時に決定されるスコープに従い、テストアナリストが設計するテストを実装および実行して、テストプロセスを継続する。

     これは明らかな誤訳ではないかと。「テスト設計」の節なのに、「実装および実行して」いるのはおかしいですね。
     「テストアナリストは、(今後)実装・実行する(ことになる)テストの設計を行う」というような意味になるかと思います。

    If the author is not the person who executes the test, other testers will need to read and understand previously specified tests in order to understand the test objectives and the relative importance of the test.
    テスト作成者がテストを実行しない場合、他のテスト担当者はテスト目的およびテストの相対的な重要性を理解するために、以前に指定されたテストを参照し、理解することが必要になる。

     「以前に指定されたテストを参照し、理解する」というのが意味不明です。が、原文を見る限り「事前に具体化されたテストを読んで、理解する」ということではないでしょうか。Aさんが事前に定義したテストケースを、Bさんが読んで理解するって話ですね。
     specifiedとかspecificという単語は訳が難しいですねえ。

    1.5.1 具体的テストケースと論理的テストケース

    Logical test cases provide guidelines for what should be tested, but allow the Test Analyst to vary the actual data or even the procedure that is followed when executing the test.
    論理的テストケースは、テスト対象とすべきものに関するガイドラインを提供し、テストアナリストが、テスト実行時に実データや手続きさえも変更することを可能にする。

     まず原則として、テストアナリストはテスト担当者とは違うロールであって、「テストを実行する人」ではないと思います。なので、「テストアナリストがテスト実行時に変更する」というのはおかしいです。
     原文を読む限り、おそらく修飾関係が違っていて、「論理的テストケースはテストすべき対象についてのガイドラインとなるが、テストアナリストは実際のデータや、テスト実行時に従う手順さえも変えることができる」ということではないでしょうか。

    1.5.2 テストケースの作成

    Depending on the scope of the testing, test analysis and design address the quality characteristics for the test object(s).
    テストのスコープに応じて、テスト分析およびテスト設計は、テスト対象の品質特性に対応させる。

     この文章の主語がわからないのですが、「対応させる」だと意味がとれません。
     「テストのスコープによっては、テスト分析とテスト設計において、テスト対象の品質特性を扱う」ということだと思います。

     今日はここまで。
     「訳文に文句つけるならおまえが訳せよ!」って話もありますが、読んでケチつけるのは楽な仕事だって自覚してますので。。。

    「IoTセキュリティのための動的テスト(ファジング)」 #IoTテストアドカレ(21)

    はじめに

     この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の21日目です。いったいいつから・・・アドベントカレンダーはその年のうちに終わると錯覚していた? 20日目はコチラ。

    kzsuzuki.hatenablog.com

    プロファイル

    • タイトル: 『Security Testing the Internet of Things IoT: Dynamic testing (Fuzzing) for IoT security』
    • 著者: Beyond Security
    • 参照サイト: Beyond Security

    ポイント

     IoTのマーケットに各製造業者が押し寄せているが、ネットワークデバイスについての経験がないことが多く、ハードウェア・ソフトウェアのセキュリティ設計・構築の複雑さは見逃されがち。プロダクトが普及した後に脆弱性が発見されると、個人・家庭内・移動体・ビジネスといった各エリアにおいて、攻撃を受けるポテンシャルを抱えてしまうことになる。

    静的テストと動的テスト

    • 静的テスト脆弱性の検出の手段としてよく使われるが、プロセッサーやメモリといった、アプリケーションのインストール先に潜む脆弱性を見つけるようには設計されていない。
    • 動的テストでは、静的テストでは見つけられない隠れた欠陥・脆弱性を見つけることができる。たとえば、古いプロセッサー上で新しいコードが動く際の脆弱性を見つけるのに重要な役割を果たす。

    ファザー

    • バイスやアプリケーションを攻撃する攻撃者は「ファザー」(fuzzer)を利用している。予期しないような壊れたデータを生成・入力したり、プロトコルの境界を狙ったりして、アプリケーションを破壊する組み合わせを探す。
    • 開発側もファザーを用いることで、脆弱性をできる限り低減しておく必要がある。ただし、多くのファザーはある特定のタイプの脆弱性プロトコルに特化していることが多い。
    • ファザーは、バッファオーバーフローエラーのテスト、プロトコル違反のテスト、ブラックボックステストなどの助けになる。
    バッファオーバーフローのテスト
    • バッファオーバーフローの問題がある場合、バッファの外にあるメモリの内容を上書きされ、悪意あるコードを埋め込まれたりするので、脆弱性の元である。
    • beSTORM™では、ヘッダを改竄したパケットを送り込んだりすることで、欠陥を検出する。
    プロトコル違反のテスト
    • バイス間の通信のために用いられるAPIに対して、攻撃が行われる。たとえば、入力値に対する誤ったバリデーション・境界値チェックや、設計の瑕疵、プロトコル自体の実装の問題を突く。攻撃の組み合わせの量が膨大になるので、もっともエラーの原因になりそうな箇所から試行したうえで、組み合わせ空間をカバーしていく。
    • 値の操作だけでなく、プロトコルの操作、ロジックの操作といった先進的なアルゴリズムが、ファザーの能力を決める要因である。
    • beSTORM™は、おそらく唯一のマルチプロトコル対応のファザー。50のプロトコルをサポートしているうえ、固有のプロトコルであっても自動的に学習することができる。
    ブラックボックステスト
    • アプリケーションの内部について知識がない場合、テスターはまずトラフィックを調べて、それをベースにして、正当な入力、ランダムな入力、おかしな入力を試す。
    • ツールでは、内部エラーを引き起こすために組み立てられた入力を、繰り返しプログラムに食わせる。「フォールトインジェクション」とも言う。
    • beSTORM™は攻撃の組み合わせを徹底的かつ賢く行い、アプリケーションの異常な動作を検出する、強力なブラックボックステストツールである。

    所感

    この文章って・・・

     ファジングについての話なのですが、beSTORM™という特定プロダクトをやたら推してくる。

    bestorm.jp

    のはまあいいとして、とにかく読みづらい・・・! 文章と文章のつながりがわかりづらい部分が多く、読み進めるのに苦労しました。で、内容も理解できない点が多かったので、いろいろ調べていると・・・。

    Open Source Fuzzing Tools

    Open Source Fuzzing Tools

     なんか、この本*1文章がものすごく似ているんですよね。読みづらいのも当然で、書籍の文章が、この記事の複数箇所に切り貼りされているんです。これは何なんだ、記事と書籍の著者が同じならいいのかもしれないけれど・・・。
     まああまり闇に突っ込みたくないので、記事では不明だった点を、書籍の方の記述に基づいて少し補足しておきます。

    ファジングの技術

     ファジングの技術として、「値の操作」「プロトコルの操作」「ロジックの操作」というのがありました。具体的には、以下のようなことみたいです。

    • 値の操作: たとえばTCPセグメントにおけるポート番号のフィールドに、記号を入れたり、RFC規定の外の数字を入れたりして、アプリケーションに送り込むこと。各フィールドの意味自体は気にせず、エラーを引き起こしそうな入力パターンを試します。
    • プロトコルの操作: たとえばHTTPにおいて、「GET GET GET」などと送り込んでみる。プロトコルのフィールドやコマンドの意味を把握したうえで、それを壊そうとする試みのようです。
    • ロジックの操作: たとえばSMTPにおいて、EHLOの前にRCPT TOを送り込む。プロトコルの正規手順を理解したうえで、例外的な手順だったり違反した手順を試して脆弱性を探すイメージでしょうか。

    ファジングって動的テストなの?

     正直申しまして、動的テストとファジングによるテストの違いがわかっていません。ファジングは動的テストの一種?
     過去にIBM AppScanを見たことがありますが、これはファザーなのか?

    www-03.ibm.com

     ネットワークセキュリティの調査では、BreakingPointに関わったこともありました。ちょっとだけ。

    jp.ixiacom.com

     なおJaSST'17 Tokyoでは、ベリサーブの松木さんが「IoT時代に立ち向かうテスト・ファジング技術入門」というチュートリアルを行う予定になっていますね。   

     ソフトウェア化していく世界のなか、まずコンピュータがクラウドという形で結実し、昨今はモノのソフトウェア化=IoTが進んでいます。実在の世界における"環境変数"を事前に想定することがどんどん難しくなっていくこれからの時代に立ち向かうために、いわゆる"異常系"の膨大なテストを実現する「ファジング」技術についてその概要、およびウェブサーバを例にとったファザー設計の実例をお話します。

     興味のある方は、受講してみてはいかがでしょうか。

     22日目はコチラです。(いつの日か公開されます)

    http://kzsuzuki.hatenablog.com/entry/ac_20161222kzsuzuki.hatenablog.com

    *1:っていうかこんな本が売られていて、かつ7,992円というのに驚いた。円安かよ。