James Lyndsay氏はAgile Testing Days 2015で"テストの巣"というタイトルのワークショップを行った。これはシステムをテストするためにどうやって膨大なテスト群を設計できるか、結果を視覚化できるかを調査し、ツールはそれにどう役立つかを紹介するものである。InfoQはこのテスティングアプローチについてインタビューを行った。
InfoQ: "テストの巣"を使うとはどういう意味かご説明いただけますか？
Lyndsay氏: 鳥の巣は何百という貧相な小片から構成されています。– 個々では無力ですが、まとまれば育っていく家族を守れるようになります。テスターとして実行できる計測は個々で考えると味気なく平凡ですが、構築を支援しているシステムの深部にある事実を見つけようとするときには役に立つのです。心地良い韻を踏むものなのです。
わたしが意味しているところは、Mike Bostock氏の "Will it Shuffle"を見てみればわかります。このページでBostock氏は1800の測定値で図を描き、シャッフルアルゴリズムの欠陥を描いています。この測定値自体もまた、このアルゴリズムを通った別個10,000の実行結果のサマリーを示しているものです。この図でBostock氏はシャッフルのバイアスを示すために色をアレンジしていて、カラフルに構成されているほどアルゴリズムに欠陥があるということがわかるようになっています。このアルゴリズムはブラウザによって異なるビルトイン関数を使っているため、同じコードでもブラウザが違えば違った創発特性、それゆえ違った欠陥を示すようになっています。ただの１回のシャッフルではこんなことはわかりませんが、1000回やればわかるのです。適切な図を選んで構成すれば、こういった違いに気付きやすくなります。
InfoQ: テストの視覚化にはどんな効果があると考えていますか？
Lyndsay氏: 視覚化は、データの情報が、自分たちが頭で描いたモデルとチームで築かれた見解に影響を与えられるようにしながら、たくさんの測定結果を形にし、脳の驚くべき視覚処理に適合させています。何千ものデータ点は一見にしかずということです。
InfoQ: ワークショップでは聴講者がどんなツールを使ってデータの視覚化しているかを訊いていましたね。人気なのはどのツールでしたか？オススメはありますか？
Lyndsay氏: Excelですね。テスターにとって万能のものでしょう。素晴らしいグラフを描写できますし、データの処理、フィルター、ソートもできますからね。しかしながら、列と列を名称で差し替えるのには不便ですね。行と比べてデータ探査するのに骨が折れるので。Splunkや Kibanaといったビッグデータツールはテスト結果の分析にとても便利だと思いますので、今年中にでも遊んでみるつもりです。グラフ描写ツールは鎖の輪のようになっているので、データの生成と応用にもツールが欲しくなります。
InfoQ: ワークショップでは、データの視覚化によく散布図を使っているとのことでしたね。どうやって実現させているのですか？
Lyndsay氏: DataGraph from Visual Data Toolsというツールを使っています。多数のテストから測定結果のテーブルを取得できますし、他のツールと比べて、どの列にもプロットしやすいです。– それから値同士の関連を明らかにするのに、要素のフィルターも色付けもリサイズもできるようになっています。DataGraphはコストがかさむし、OS Xでしか動かないのですが、いいオープンソースのツールがあります– Raw by DensityDesign というものです–ブラウザで動きますし、散布図も優れています。
InfoQ: 自動生成されたテストを使うのはどんな場面がオススメでしょうか？
Lyndsay氏: 探索的テストで部品を動作させたとき、面白い問題がすぐに見つかりました。例えば、コードとか単体テストは入力値の１つかそれ以上の範囲を取るアルゴリズムを使うでしょう。もしこのアルゴリズムをランダムなポイントだけでチェックするなら、変数の組み合わせに関して細かい、または広い範囲でテストを生成しますし、興味深いポイントを示すためにグラフを使います。
結合テストで新たな発見はないか探していたときにも非常に良い結果を得ました。とりわけ、部品が異なる技術で構成されている場合や協力なパーツでシンプルに解決されている場合です。
特に新しいことはありませんが、性能テストとファジングには明らかな類似点があると言えます。
InfoQ: どんなときには避けた方がいいですか？
Lyndsay氏: すぐ動作が難しくなるようなシステムの一部に限ります。ツールをうまく扱う必要がありますし、網羅した感覚には常に疑いを持たなければなりません。–広いように見えますが、概して深いものなのです。計測値が何回予想通りになったとしても、動作を検証するのは効果的な方法ではありません。
コードを書いた同僚に、たまにイラつくことはありませんか？でも真実を見つけるために意地悪になるべきは、単なるコードだけではない、自身が構築したシステムに対してなのです。
InfoQ: このテストアプローチのメリットは何ですか？
Lyndsay氏: システムの挙動範囲を明らかにするのに早くて安い方法であるということです。–もし挙動に変なところがあれば、自分たちが作り出した本質とリスクに近付いて理解できるチャンスを得られるのです。