探索的テスト（たんさくてきてすと）：情報マネジメント用語辞典

exploratory testing / 探索型テスト

　事前・直前のテスト結果に応じて、次のテストを適宜に施していくソフトウェアテストの方法をいう。探りを入れながら臨機応変にテスト項目を決めていくテストスタイルといえる。

　伝統的なソフトウェアテスト（記述的テスト）は、事前に定義したテストケースを順番にすべて適用する形でテストを実施する。これに対して探索的テストは任意のテストを実施し、その結果を見てから次のテストケースを作る。テストを網羅的に行うのではなく、怪しい個所を探し出し、順次絞り込んでいくアプローチだといえる。

　テストの実行を通じて対象ソフトの特徴の情報を“探索”する技法なので、「テスト実施とテスト計画、学習を同時並行して行う対話的プロセス」といった定義もある。ここでいう学習は実行コードの挙動を観察する以外に仕様書や既存のテストケース、ソースコードを参照してもよい。必要に応じては開発者ともコミュニケーションをとるべきだろう。

　探索的テストは即興的にテストケースを作っていくので、場当たりな作業と同一視されがちだが、基本的なテスト計画や目的、スケジュールなどは設定される。チャーター（原則）と呼ばれる文書でテストの方向性を指定することもある。

　事前知識がない（あるいは少ない）状態で、テスト対象の挙動が「おかしい」「不自然だ」と気付き、その不具合の所在をあぶり出すには、豊富な経験と優れた洞察力が必要となる。こうしたスキルのあるテスト技術者が探索的テストを行った場合、怪しい現象に対して適切なテストを多角的に実施できるので、機械的にテストケースを適用するだけでは見出せなかった不具合に到達できることが多い。

　探索的テストはエラー推測と同様、昔から行われてきたもので、従来はアドホックテストとも呼ばれてきた。1990年代になって、アドホックテストが“いい加減”の意味を強く帯びるようになったことから、コンテキスト駆動派（Context-Driven School）を名乗るグループが「探索的」という語を使うようになったという。文献上の初出は、セム・ケイナー（Cem Kaner）らの書著『Testing Computer Software』（1999年）だとされる。

　探索的テストは、未完成でも動作するソフトウェアと経験あるテスト技術者がいれば、実施可能である。そのため、仕様が未確定のままに開発を進めざるを得ない場合、記述的テストの準備時間がない場合、記述的テストの信頼性に不安がある場合（欠陥検出数が極端に少ないなど）に有効な方法である。あるいは検出済み問題の追跡――すなわち原因の追及、不具合範囲の特定、バリエーションの発見などにも利用される。

　探索的テストは現状、テスト技術者の個人的経験や直感に依存した方法であるため、記述的テストのように事前にテストケースをレビューできず、属人的になりがちである。また、定量的な指標を算出しにくいので品質保証には向かず、どんなテストが行われたのかについて正確な記録がされにくいと指摘されることがある。

　探索的テストと記述的テストは相互補完的な方法なので、双方をバランス良く組み合わせて実施することが重要となる。