探索的テストと他のテストを比べてみる。

　試験前になると部屋の掃除をしたくなる現象がありますが、『システムテスト自動化 標準ガイド』（通称「ギア本」）の出版プロジェクトでレビューゾンビと化していた時にも「うおーっ、これも勉強したいあれも勉強したい、ブログも書きたいし焼き肉も食べたい！」と、意識高い系になっていました。

システムテスト自動化 標準ガイド CodeZine BOOKS

第3象限にある探索的テスト

　探索的テストも、ぜひ学びたい分野の1つです。
　ソフトウェアテストにおいてわたしが特に興味を持っているのは、アジャイルテスト4象限で言うと上の2つ。「ビジネス面」に属する第2象限と第3象限です。

　第2象限の機能テストは「自動と手動」とされていますが、この自動化が進むとどうなるか。ギア本の第1章で、著者らは以下のように言っています。

手動で実行すべきテストがわずかしか残っていないなら、テスト担当者はよりよい手動テスティングをすることができる。

　自動テストによって浮いた時間は、開発の遅延を吸収するためにあるのではなく「よりよい手動テスト」を行うためにある。これは第3象限に属するテストであり、その1つが探索的テストです。

　探索的テストは、この言葉を生み出した Cem Kanerによって次のように定義されています。（Wikipediaより、鈴木訳）

a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.
　テスター一人ひとりの自由と責任を前面に出し、 テストに関する学習、テスト設計、テスト実行、そしてテスト結果の解釈を、プロジェクトを通じて並行に、かつ相互補完的に行われるアクティビティと捉えることで、テスターの仕事の質を継続的に最適化するスタイル。

　探索的テストは、割と誰でも知っているし、実践例も公開されていながら、いまひとつ情報がまとまっていないように感じる。この点、「レビュー」と似ているように思います。当事者の経験やスキルに大きく依存して、進め方やノウハウがいまいち整理しがたい印象。
　一方で某MLのトピックを読んでいると、先進的な人たちはどんどん新しい取り組みをしているようで、全然追いつけていないのが現状です。

他のテストと探索的テスト

　わたしは初心者ですので、「そもそも探索的テストとは」というところから勉強していきます。探索的テストがどういうものかを知るために、探索的テストとよく対比される、4つのテストとの違いを考えてみました。

スクリプトテストと探索的テスト

　1つ目は、スクリプトテスト（scripted test）です。
　ここでいう「スクリプト」とは「手順」を指します。実行する手順が事前に（ある程度）しっかり決まっているテストであり、テストケースの設計・実装（テストケースへの落とし込み）は、実行とは分離されています。一般的に「テスト」といって思い浮かぶ「普通の」テストが、スクリプトテストです。

　一方、探索的テストでは、この3つを同時に行うことになります。入力に対するプロダクトの反応を見て、プロダクトを学び、次の入力を「その場で」決めます。これを simultaneous learning と呼ぶこともあります。
　もちろんスクリプトテストであっても、ヒトの心を持ったテスターであれば、ある程度は探索的テストの要素を（意識せずに）取り込んでテストを進めているでしょうが、探索的テストではこれを明示的に行います。

自動テストと探索的テスト

　2つ目は、自動テスト（automated test）です。
　ソフトウェアが返す出力に応じて次の入力を選ぶという探索的テストでは、手順はその場で、テスターの裁量によって決まっていきます。よって、自動化とは相性が悪い。

　自動テストの長所の1つは、「決められた手順をまったく同じように実行してくれる」というものですが、それは裏を返すと、「まったく同じようにしか実行してくれない」ということでもあります。
　テストケースを手動で実行している場合、そのテストケースで確認しようと思っていたのとは違うポイントで欠陥が見つかることが珍しくありません。場合によっては、テストケースの前提条件を揃えるための段階で、おかしな動作を見つけることもあるでしょう。
　人間による手順の「ゆらぎ」「きまぐれ」「思いつき」「ふとした寄り道」によって見つけられる欠陥を、探索的テストではカバーすることができます。

要求に基づくテストと探索的テスト

　3つ目は、要求に基づくテスト（requirements-based testing）です。
　テストケースは、要求仕様書、設計書、マニュアルといったドキュメントをベースに作成されるのが一般的です。一方、探索的テストではこれらを参考にしつつも、書いてあることそのものを検証することのみを目的とはしていません。仕様には現れない暗黙の前提やユーザビリティ、プロダクト全体の一貫性といった点で、探索的テストが力を発揮することがあります。

モンキーテストと探索的テスト

　4つ目は、モンキーテスト（monkey testing）です。
　モンキーテストとは、猿がタイプライターのキーを叩くように、意志も方針も戦略もなく、ランダムに進めるテストのことです。「純粋な」スクリプトテストが考えづらいのと同様、「純粋な」モンキーテストを行えるテスターがいたら、逆に怖いですね。

　探索的テストでは、テスト実行のアクティビティがモンキーにならないよう、事前の準備が必要であることが強調されます。その準備は、プロダクトに関するドキュメントに基づくものかも知れませんし、プロダクトの目的から一般的に想像できる「あるべきシナリオ」かも知れません。まともなテストオラクルが期待できない環境にあっては、探索的テストが唯一の有効なテストということもありそうです。
　よりフォーマルには、探索すべきことを（ゆるやかに）規定した「チャーター」を準備する場合もあります。

でもやっぱりわからない

　このように見てくると、探索的テストがどういうものであるか、「何となく」はわかります。
　しかし、探索的テストを実行する前提として、ドメイン知識、テスティングの知識を前提とする人もいれば、まっさらな状態でも有効にテストができる技法として紹介する人もいます。
　チャーターについての説明を読んでも、どの粒度で、どんなことを書くのがいいのかを具体的に説明してくれる資料はあまり見当たりません。
　また人によっては、スクリプトテストをするのは時間の無駄で、経験者ならすぐに探索的テストにとりかかるべき、という主張をしています。個人的には探索的テストが「効率的」*1であることには賛成しますが、網羅的、あるいは効果的でもあるかというと、そうではないと思います。

　わたしは今、「探索的テスト読書会」という形で、有志と『Explore it!』の輪読をしながら知見を交換していますが、来年はこの活動をさらに前向きなものにしていきたいと思っています。

Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing

　またこの会の活動と並行して、ネット上に公開されているブログ記事や論文、パワポ資料などをむやみに集めて、いろんな人が探索的テストをどのように語っているのかを蓄積していくつもりです。多くは英語なので、遠回りではありますが、英語を読む練習もしないとね・・・。

　ということで、情報蓄積の箱はここに用意しています。勝手に「ポータル」を名乗っている！

探索的テスト研究会

　用意しただけで、ネタは全然たまっていません。週に1行追加するペースで、充実させていきたいと思います。
　すぐに誰かの役に立つようなものではありませんが、自分のモチベーションのために、宣言しておきます！

*1:「効果的」と「効率的」のここでの定義については、この記事も参考にしてください。