探索的テストとは
探索的テストとはテスト担当者のスキルやテスト経験をもとにテストを行う経験ベースのテスト技法の一つです。JSTQBの用語集（Japan Software Testing Qualifications Board：ソフトウェアテスト技術者資格認定の運営組織）では「テスト担当者がテストアイテムや以前のテストの結果の知識や調査情報を使用して、テストを動的に設計、および実行するテストアプローチ」と定義されています。
探索的テストのやり方
探索的テストは、テストを行う中で、テスト対象のシステムを学習して次にどういったテストをすれば欠陥が見つかるかを考えたり、特定の利用者が特定の目的を達成しようとする上でどのようなテストが必要かを考え必要に応じてテストケースを追加していきます。探索的テストは一般的に以下の手順で実施します。
- テスト目的の定義
探索的テストの目的を明確にしてテストチャーターなどに記載します。
- テスト環境を準備する
目的を達成するために必要なテスト環境を準備します。
- テスト実施
実際にテスト対象に触れながら理解を深めて、どういったデータを使って操作をするか検討しながらテストを実施します。想定外の動作やエラーが発生した場合、原因を調査して必要に応じてテストを追加します。
- テスト結果記録
発見した欠陥、問題点、改善点を報告書などに記録します。この情報は管理者や開発者へのフィードバック時に役立ちます。
- 結果評価
テストマネージャー等が４のテスト結果記録をもとにテスト結果を評価し、今後の品質向上につながる施策などを検討します
スクリプトテスト（記述式テスト）との違い
スクリプトテストは「テスト計画→テスト設計→テスト実行」の順にテスト工程を進めていき、仕様書や設計書などのテストベースをもとに作成したテストケースに沿ってテストを実施します。
テスト開始前に仕様を理解し、テスト手順やテスト条件が具体的になっているテストケースを準備しておくことで、テスト実施時の属人性を軽減できたり、網羅的に仕様をテストできたりといったメリットがあります。しかし、テストケースを事前に準備してからのテストになるため、その分、工数がかかってしまったり、テストケースに沿ってテストを実施するため、テスト実施中の気づき事項をテストに反映しづらいといったデメリットもあります。
このようなスクリプトテストに対して、探索的テストは事前にテストケースを準備せず、動的に「テスト設計→テスト実行」の順にテスト実施し、そのテスト結果を確認しながら次のテストを考え、テストを繰り返していきます。、また、テスト実施中の気づき事項をテストに反映していきます。スクリプトテストと探索的テストにはこうした違いがあり、互いを補完し合う関係にあるため組み合わせて使用することが多くなっています。
モンキーテストとの違い
モンキーテストは「仕様を全く理解していない猿にテストを実施させる」という意味で、テストの目的を定めずに場当たり的に実施するやみくもなテストと位置づけられています。テスト経験の浅い担当者でも実施可能で、効果的なテストができるかは不確定要素が大きいです。一方で、探索的テストはテストの目的や方針を決めた上でテスト担当者の知識や経験をもとに効率的に欠陥を検出するテストです。事前にテスト設計などの準備が不要という点では探索的テストと似ていますが、こうした違いがあります。
アドホックテストとの違い
アドホックテストにはいくつか定義があるため、本記事では「一定の仕様理解のある技術者が狙いをもって実施するテスト」と定義します。狙いというのは、例えば「特定の問題に絞ってテストを行いその問題の修正方法や対処法を発見する」場合に活用されます。一方で、探索的テストはテスト担当者がシステムを学習していきながら、テスト観点を発見してテストを行う手法です。
よって、アドホックテストは、ある特定の狙った問題を解決する際に活用される一方で、探索的テストは、より広範囲にシステムを理解していきながら、システム全体の品質を向上させるために活用します。
アジャイル開発における探索的テスト
探索的テストは、事前にテストケースを準備する必要がないため、仕様書や設計書などのドキュメントが不十分な状況でも実施できます。テストケースの準備には、多くの工数を必要とするケースが多々あるため、テストケースの作成工数を削減できる点は工数的なメリットが大きいです。
このように、テストケースの作成工数を削減することでスピーディーにテストを開始できるため、開発速度が重視されるアジャイル開発に導入されるケースが増えてきています。
探索的テストのメリット・デメリット
テスト技法のメリット・デメリットを理解した上で、どのテスト技法を採用するか検討することでより効果的なテストを実施できます。ここでは、探索的テストのメリットとデメリットを説明します。
探索的テストのメリット
効率よく欠陥を発見できる
探索的テストでは、テストを実施しながらテスト対象のシステムを学習していきます。次にどういったテストを実施すれば欠陥が見つかるかを考えたり、特定の利用者が特定の目的を達成しようとする上でどのようなテストが必要かを考え必要に応じてテストケースを追加していきます。このようにテスト実行中の気づきをその場でテストに反映できる点がメリットです。
テスト実行中に欠陥が潜んでいそうな箇所を集中的にテストをしたり、スクリプトテストなどでテストケースを準備するような段階では気づきにくいような機能の振る舞いをテストすることで、効率よく欠陥を発見することが可能です。
工数・コストを抑えやすい
テストケースを作成するためには、仕様書を読解し、仕様を把握してどのようなテストを実施するか検討したうえでテスト設計をする必要があります。作成したテストケースはレビューをして、レビューで指摘があれば修正します。こうした工程を通してテストケースは作成されるため工数がかかります。
テストケース作成自体にかかる工数以外にも、各工程のなかでは、関係者間のコミュニケーションコストもかかってきます。例えば仕様を理解するなかで、仕様書に不備が見つかった場合にはテストケース作成ができないため、開発者への仕様の確認作業が必要になります。また、仕様に変更が生じた場合はテストケースを修正する必要があるため、メンテナンスコストもかかってきます。探索的テストではこうした工数・コストを抑えられる点がメリットです。工数が逼迫していてテストケースの準備が難しい場合に効果が大きいです。
仕様書や設計書などのドキュメントがなくても実施できる
探索的テストはテスト担当者がテスト対象を動作させながら、自身の知識や経験をもとにどのようなテストを実施するかを判断するため、仕様書や設計書などのドキュメントが不十分な場合でも適用できます。JSTQB-FLシラバス(Version 2018V3.1.J03)にも「仕様がほとんどなかったり、不十分であったりする場合に最も効果が大きい」と記載されています。仕様書が完成するのを待たずに先行してテストを開始できたり、アジャイル開発のように仕様をドキュメントに十分に記載しないような場合でもテストを実施できる点は大きなメリットです。
柔軟性が高い
スクリプトテストではテスト設計の段階であらかじめ決めたテスト技法にもとづきテストを進めていくため、テスト中によりよいテスト方法があることに気がついても、テストへの反映は時間的に難しいことが多いです。探索的テストでは、テスト実施中にテスト担当者の経験にもとづいて、状況に応じた最適なテスト技法を適用できます。このように柔軟性高く臨機応変にテストが行えるため、スクリプトテストでは検出できないような欠陥を検出できることもあります。
暗黙知を活用できる
暗黙知は個々の経験や学習で習得した、意識的に認識していない知識です。人が行動するなかで無意識に行う動作などを指します。テスト担当者に自由度を持たせ、知識や経験を活かす探索的テストでは、このような暗黙知を活用できます。
また、テスト内容が具体的に記載されたテストケースに沿ったテストでは、テスト中に疑問が生じることは少ないですが、仕様書が不十分な状態でもテストを実施する探索的テストでは、テスト中に疑問点や不明点が生じることがあります。そのため、設計者や他の担当者に質問をして次のテスト内容を考えることも多々あります。そのタイミングで互いの暗黙知が共有されてテストに活用できる点もメリットです。
探索的テストのデメリットとその対策
テスターのスキルや経験に依存する
探索的テストはテスト担当者のスキルや経験をもとにテストを実施しますが、テスト担当者といっても「経験の浅い担当者」から「熟練のテスト担当者」までさまざまでテストの効果にバラツキが出る可能性があります。もし、テスト担当者の経験が不足していると、単なる思いつきのテストになってしまい期待した効果を得られないかもしれません。
こうした、経験のバラツキを軽減するためには、テストチャーターが有効です。テストチャーターはテストの目的や観点を記載します。作成したテストチャーターをテスト担当者間で共有して、テストを実施することで経験のバラツキを軽減することができます。
テストを資産化できない
探索的テストでは、基本的にはテスト仕様書やテストケースといったドキュメントを作成しないため、テストを資産化できません。ドキュメントを作成しておくと、以前テストしたシステムと似たシステムをテストする際に活用してテスト品質を高めるのに役立ちます。
探索的テストは過去のテストノウハウを共有しにくいため、探索的テストで実施したテストアイデアや発見した問題のなかで、他のテスト担当者や開発チームにも役立つ情報があれば会議やワークショップなどを開催して共有しておくといいでしょう。
網羅性が担保できない
探索的テストは事前に具体的なテスト内容を定義せずにテスト担当者に自由度を持たせてテストを実施するため、テストがどの程度の範囲を網羅して実施されたかどうかの判断が難しくなります。これは、探索的テストには公式なテストカバレ ッジ基準が存在しないため、カバレッジの計測が困難であったり、テスト対象の優先順位もテスト担当者によるため不明確であったりすることからきています。そのため、探索的テストはブラックボックステスト技法やホワイトボックステスト技法などカバレッジの計測が可能な他のテスト技法と組み合わせて適用することが多くなっています。
管理・コントロールが難しい
探索的テストでは詳細にテスト計画を立ててテストを実施しないため、テスト期間、対象範囲、テストの量などが管理・コントロールしづらくなります。
この対策としては、あらかじめテスト期間を一定期間に区切って探索的テストを実施するセッションベースドテスト（セッションは一定の時間の意味）といわれる方法が有効です。セッションが変わるタイミングでテスト担当者が管理者にテストの実施状況を共有することで、管理者はテストの実施状況を把握でき、管理・コントロールしやすくなり、テスト担当者も管理者からのフィードバックを受けられるようになります。
非機能テストに向かない
非機能テストはユーザビリティといった使いやすさやシステムがどれくらいの負荷に耐えられるかや十分なパフォーマンスを発揮しているかなど機能以外の部分をテストします。非機能テストには、テスト環境の構築に時間を要したり、一定の目標値が定められ、その値を満たしているかを検証するケースが多いため、テスト担当者の知識、経験で判断できるような観点が少なくなります。テスト担当者の経験からランダムにテスト対象を動作させて結果を確認する探索的テストでは、非機能要件を保証する方法としては適していないでしょう。非機能テストと探索的テストは別として、探索的テストは機能テストやユーザビリティテストに対して適用した方がよいでしょう。
まとめ
探索的テストはスクリプトテストのように事前にテストケースの準備をする必要がないため、開発スピードが重視されるアジャイル開発との相性がよいテスト手法です。テスト担当者の知識・経験を活かしてスクリプトテストでは検出しにくいような欠陥を効率的に検出できる可能性が高いです。しかし、テスト担当者の経験が浅いと単なるやみくもなテストであるモンキーテストになる恐れもあります。また、カバレッジ基準がないため網羅性を担保しづらくなるため、スクリプトテストと組み合わせて使うなどするとよいでしょう。このように、各テスト技法の特徴を抑えたうえで、組み合わせて適用することで効果的なテストを実施できます。
