探索的テストとは？目的・やり方・モンキーテストとの違いを徹底解説
探索的テストは、テストの設計と実行を同時に進める柔軟なテスト手法です。この記事では、モンキーテストとの違い、目的と3つのデメリット、押さえるべき観点、実施方法、よくある失敗例まで、実践に必要な知識を体系的に解説します。この記事を読むことで、探索的テストの正しい理解が得られ、自分のチームでどのように導入・活用すればよいかが明確になります。
目次
探索的テストとは
探索的テスト(Exploratory Testing)とは、テスト対象について学習しながら、テストの分析、設計、実行を同時に進めていくテスト手法です。
ISTQB（International Software Testing Qualifications Board）の用語集では、探索的テストを「テスト担当者の知識、テストアイテムの探索、および過去のテスト結果に基づいて、テストを動的に設計し実行するテストアプローチ」と定義しています。また、JSTQBのFoundation Levelシラバス（v4.0）では、「テスト担当者がテスト対象について学習しながら、テストケースを同時に設計、実行、評価する」と説明されており、テスト実行を通じて製品への理解を深める「学習」の要素が重視されています。
探索的テストの概念は、1980年代にCem Kaner氏によって提唱されました。従来のスクリプトテスト（事前にテストケースを設計してから実行するテスト）とは異なり、テスト担当者がテスト対象を操作しながら、その動作や結果から新たなテスト観点を見出し、次のテストにつなげていきます。
なお、「アドホックテスト」という用語と混同されることもありますが、両者は区別されます。アドホックテストは「場当たり的なテスト」という意味合いが含まれ、後述のモンキーテストに近いものとして捉えられる場合もあります。一方、探索的テストはテストチャーターやセッションベースドテストなど、より体系的なアプローチを含む点が異なります。
探索的テストとモンキーテストの違い
探索的テストの定義や特徴を見てきましたが、実際には「モンキーテスト」という似た手法と混同されることがよくあります。両者は一見似ているように見えますが、目的や進め方に明確な違いがあります。
| 観点 | 探索的テスト | モンキーテスト |
|---|---|---|
| 目的 | バグの発見、製品理解の深化 | ランダムな操作による予期しない不具合の発見 |
| 計画性 | テストチャーターなどで方向性を定める | 特に計画なし、ランダムに操作 |
| テスターのスキル | 経験や知識が求められる | 特別なスキルは不要 |
| 記録 | テスト内容や結果を記録する | 記録しないことも多い |
| 学習要素 | 操作しながら製品を理解していく | 学習要素は重視しない |
モンキーテストは、文字通り「猿がキーボードをランダムに叩くように」テスト対象を操作する手法です。予期しない入力や操作によって、通常のテストでは見つからない不具合を発見できる可能性があります。
一方、探索的テストは、テスターが製品知識や過去のバグ傾向などを活用しながら、意図を持ってテストを進めます。「ランダム」ではなく「戦略的」にテストを行う点が、モンキーテストとの大きな違いです。
どちらが優れているというわけではなく、目的に応じて使い分けることが重要です。
探索的テストの目的
探索的テストとモンキーテストの違いを理解したところで、次は「なぜ探索的テストを行うのか」という目的について見ていきましょう。探索的テストには、スクリプトテストにはない大きく2つの目的があります。
スピードの速さ
探索的テストでは、テストの分析・設計と実行を並行して行うため、テスト開始までの時間を大幅に短縮できます。
スクリプトテストの場合、テスト設計などを通じてテストの手順や期待結果を明らかにしてからテスト実行に入ります。探索的テストでは、設計プロセス自体がなくなるわけではありませんが、詳細なテストケースドキュメントを事前に作成する時間を削減できます。そのため、開発サイクルが短いアジャイル開発との相性が良いとされています。
柔軟性が高く、人間の能力を活かせる
探索的テストでは、テスト中に発見した情報をもとに、その場でテスト方針を変更できます。
テスト対象を実際に操作してリアルタイムにフィードバックを得ることで、テスト担当者が過去に経験した不具合のパターンや、「何かおかしい」という違和感・直感をもとに、ピンポイントでバグを狙いに行くことができます。
スクリプトテストでは、事前に設計した手順に沿って実行するため、このような「その場の気づき」を活かしにくい面があります。探索的テストでは、人間ならではの判断力や経験知を活用し、固定されたテストケースでは見つけにくいバグを発見できる可能性が高まります。
探索的テストのデメリット
探索的テストでは、スピードの速さと柔軟性という2つのメリットがありますが、注意すべき課題もあります。ここでは主に3つのデメリットについて解説します。
テスターの経験やスキルに依存する
探索的テストの品質は、テスターの能力に大きく左右されます。
経験豊富なテスターは、「バグが潜みやすい箇所」を直感的に把握し、効率よくテストを進められます。一方、経験が浅いテスターは、どこをどのようにテストすればよいかわからず、テストの効果が限定的になる可能性があります。
この属人性は、チームでテストを行う際の課題となります。
テスト設計の品質がわかりにくい
探索的テストでは、事前にテストケースを作成しないため、「何をどこまでテストしたか」を客観的に評価しにくいという課題があります。
スクリプトテストでは、テストケースの消化率やカバレッジなどで進捗を把握できます。しかし探索的テストでは、このような定量的な指標を設定しにくく、テストの網羅性や妥当性を判断するのが困難です。
記録が残りにくい
探索的テストでは、テスト実行中に何をテストしたかの記録が残りにくいという課題があります。
バグを発見しても、その再現手順を正確に把握できていないケースも起こりえます。また、テストで得られた知見がテスター個人の中に留まり、チームのナレッジとして蓄積されにくいという問題もあります。
この課題に対しては、後述するセッションベースドテストの導入が有効です。
探索的テストで押さえるべき観点
探索的テストのメリットとデメリットを理解したところで、次は「どうすれば効果的な探索的テストができるのか」という実践面に移りましょう。探索的テストを効果的に行うには、いくつかの観点を意識することが重要です。JaSST'18 Tokyoのワークショップ資料では、探索的テストに必要な3つの要素として「テスト技術」「製品知識」「バグの知識」が挙げられています。
テスト技術
同値分割、境界値分析、状態遷移テストなど、様々なテスト技法の知識があると、探索の幅が広がります。「この機能にはどの技法が効果的か」を判断できると、より効率的にバグを発見できます。
製品知識
テスト対象の製品に関する知識は、探索的テストの質を大きく左右します。製品の構成、アーキテクチャ、ドメイン固有の情報、ユーザーがどのように使うかといった知識があると、テストの方向性を適切に定められます。
バグの知識
過去にどのようなバグが発生したか、どのような条件でバグが起きやすいかという知識も重要です。「この製品は〇〇の処理でバグが多い」「この言語では△△の問題が起きやすい」といった傾向を把握していると、重点的にテストすべき箇所を見極められます。
これらの知識をインプットとして、テスト実行中に「怪しい動き」「違和感」を感じ取り、仮説を立てて検証を繰り返すことで、バグの発見と製品理解の深化につなげていきます。
探索的テストの種類と実施方法
ここまで、探索的テストを効果的に行うために必要な3つの観点（テスト技術、製品知識、バグの知識）を見てきました。次は、これらの観点を活かしながら、実際にどのように探索的テストを進めていくかを解説します。 探索的テストには、主に3つの実施方法があります。それぞれの特徴と適用場面を理解し、状況に応じて使い分けましょう。
| 種類 | 特徴 | 適した場面 |
|---|---|---|
| テストチャーター | 簡潔な指示書でテストの方向性を定める | チームでテストする場合、テスト範囲を明確にしたい場合 |
| セッションベースドテスト（SBT） | 時間枠を設けて記録を残しながら実施 | 進捗管理が必要な場合、テスト結果を蓄積したい場合 |
| フリースタイル | 制約なくテスターの判断に委ねる | 製品の初期段階、経験豊富なテスターによる探索 |
テストチャーターを用いる探索的テスト
テストチャーターとは、探索的テストの「道しるべ」となる簡潔な指示書です。テストの方向性を定めつつ、具体的な手順は定めないことで、柔軟性を保ちながらもテストの焦点を絞れます。
テストチャーターのテンプレートとして、書籍『Explore It!』（Elisabeth Hendrickson著）で紹介されている以下のような形式がよく使われます。
〈ターゲット〉を〈ツール / データ〉を使って探索し、〈リスク / 情報〉を発見する
例えば「決済処理の不整合を発見するために、異常系のテストデータを使って、カート機能を探索する」のように記述します。
テストチャーターを用いることで、完全に自由な探索的テストよりも方向性が定まり、かといってスクリプトテストほど縛られない、バランスの取れたテストが可能になります。
セッションベースドテスト（SBT）
セッションベースドテストは、時間枠（セッション）を設定してテストを行う方法です。一般的には30分〜2時間程度のセッションを設け、その中で特定のミッション（テスト目的）に取り組みます。
セッションベースドテストの基本的な流れは以下のとおりです。
- セッションの開始：ミッション（テスト目的）を明確にする
- テスト実行：時間内でミッションに沿ったテストを行う
- 記録：テスト内容、発見した問題、気づきを記録する
- デブリーフィング：セッション終了後にテスト管理者と振り返りを行う
セッションベースドテストのメリットは、探索的テストの柔軟性を保ちながら、進捗管理や記録を残せる点です。デメリットとして挙げた「記録が残りにくい」という課題を軽減できます。
フリースタイルの探索的テスト
フリースタイルは、テストチャーターやセッションの制約を設けず、テスターの判断に委ねる最も自由度の高い方法です。
テスターの創造性を最大限に発揮できる反面、属人性が最も高くなります。経験豊富なテスターが、製品の初期段階で「どこに問題がありそうか」を素早く把握したい場合などに適しています。
フリースタイルの探索的テストは、テストチャーターやセッションベースドテストと組み合わせて使うことも効果的です。例えば、最初はフリースタイルで製品を触り、気になる箇所を見つけたら、その箇所に焦点を当てたテストチャーターを作成するといった使い方ができます。
探索的テストの具体例
探索的テストの実施イメージを具体的に見てみましょう。ここでは、ECサイトの「商品検索機能」をテスト対象とした例を紹介します。
テストチャーターの例
商品検索機能を、様々な検索条件を使って探索し、検索結果の表示に関する不具合を発見する
テスト実行の流れ
- まず、通常の検索キーワードで動作を確認する
- 検索結果が多い場合と少ない場合で表示を確認する
- 検索結果が0件の場合の表示を確認する
- 途中で「特殊文字を入れたらどうなるか」という疑問が浮かび、記号や絵文字を入力してみる
- 「検索結果を絞り込んでから、さらに検索したらどうなるか」と考え、複合的な操作を試す
- 「ページを素早く遷移したら表示が崩れないか」と考え、高速な操作を試す
このように、事前に決めた手順を実行するのではなく、操作しながら「次は何を試そうか」と考え、その場で判断してテストを進めていきます。
発見できる可能性のあるバグの例
- 特殊文字を入力するとエラーが発生する
- 検索結果が大量にあるとページの読み込みが極端に遅くなる
- 絞り込み条件を解除しても、検索結果が元に戻らない
これらは、事前に設計したテストケースでは見落としがちな問題です。
なお、近年では人間が行ってきた探索的テストの一部を、生成AIに補助させる取り組みも始まっています。MagicPod Autopilot機能を活用して探索的テストを行った事例もありますので、興味のある方はぜひご参照ください。
探索的テストでよくある失敗例と対策
探索的テストの3つの実施方法（テストチャーター、セッションベースドテスト、フリースタイル）と具体例を見てきました。しかし、実際に導入する際には、いくつかの落とし穴があります。探索的テストを導入する際によくある失敗パターンと、その対策を紹介します。
失敗例1：目的なく漫然とテストしてしまう
「とりあえず触ってみる」という姿勢で始めると、同じ箇所を繰り返しテストしたり、重要な機能を見落としがちです。
→ 対策：テストチャーターを作成し、テストの方向性を明確にしましょう。完全な自由よりも、ある程度の指針があった方が効果的なテストができます。
失敗例2：記録を残さない
探索的テストの柔軟性を重視するあまり、何をテストしたかの記録を残さないと、バグの再現ができなかったり、同じテストを何度も繰り返したりする問題が起きます。
→ 対策：セッションベースドテストを導入し、セッションごとにテスト内容と結果を記録する習慣をつけましょう。
失敗例3：同じ箇所ばかりテストしてしまう
テスターの得意分野や関心のある機能ばかりテストしてしまい、テスト範囲が偏ることがあります。
→ 対策：テスト技法の知識を活用して、バリエーション（CRUD操作、境界値、状態遷移など）を意識的に試しましょう。複数人でテストする場合は、担当範囲を分けることも有効です。
失敗例4：経験が浅いテスターに丸投げ
探索的テストはテスターのスキルに依存するため、経験が浅いテスターだけに任せると、十分な効果が得られないことがあります。
→ 対策：ペアテスト（2人1組でテスト）を導入したり、経験豊富なテスターがメンタリングを行ったりすることで、スキルの伝達と品質の担保を両立できます。
まとめ
探索的テストは、テスト設計とテスト実行を同時に行う柔軟なテスト手法です。アジャイル開発との相性が良く、仕様書が不完全な状況でも実施できるというメリットがあります。
一方で、「テスターのスキルに依存する、進捗管理が難しい、記録が残りにくい」といった課題もあります。これらの課題に対しては、テストチャーターやセッションベースドテストを活用することで対処できます。
探索的テストは、スクリプトテストと対立するものではありません。両者を適切に組み合わせることで、より効果的なテスト戦略を構築できます。まずは小さな範囲で探索的テストを試してみて、チームに合った進め方を見つけていくことをおすすめします。
