探索的テストの進め方｜規律ある4ステップ実践ガイド

複数の受託案件を同時に抱え、テストは開発エンジニアが兼任している。リリース直前になって「本当にこれで品質が担保できているのか」と不安になる。そんな現場は少なくありません。

「探索的テストを試したいが、無計画な手当たり次第と何が違うのか、上司にもメンバーにも説明できない」。この一言に心当たりがある方に向けて、本記事は書かれています。

ここで扱うのは定義論ではありません。探索的テストの進め方を、明日から実際に1セッション回せる実行マニュアルとして解説します。

探索的テストは手当たり次第ではなく、規律ある活動です。この一点さえ腹落ちすれば、経験の浅いメンバーでも一定の質を出せる状態に近づけます。計画・実行・記録・報告という4つのステップに沿って、順番に見ていきましょう。

探索的テストの進め方は「規律ある4ステップ」

最初に、定義と誤解を数行で片づけます。以降は実務手順に集中します。

探索的テストとは何か。Copeland『はじめて学ぶソフトウェアのテスト技法』によれば、この手法は Cem Kaner『Testing Computer Software』で提唱されました。同書が紹介する James Bach の定義はこうです。「探索的テストとは、学習・テスト設計・テスト実行を同時並行で行う活動である」（by James Bach）。

つまり、あらかじめ全てのテストケースを固めてから実行するのではなく、動かして得た気づきを次のテストに即座に反映していく。この「学びながら攻める」姿勢が核心です。

「同時並行的な学習」とは何を指すか

同じく Bach は、次のようにも述べています。「次に行うテストがその前のテストの結果に何かしら依存するのであれば、ある程度の探索的テストを行っている」。ここで大切なのは「ある程度」という程度の話であって、白か黒かではないという点です。

多くのテスターは、意識せずともこの探索を日常的に行っています。それを再現可能な形に規律化するのが、本記事のねらいです。

手当たり次第（アドホック）との決定的な違いは”規律”

「探索的テスト＝行き当たりばったり」という誤解は根強く残っています。しかし両者は対極にあります。

場当たり的テスト（アドホックテスト）は、焦点が不明確で、注意が行き届かず、ずさんになりがちな実践態様を指して使われます。一方、探索的テストはスキルと経験を要する規律ある活動です。

補足すると、「ずさん・スキル不要」はアドホックテストの用語定義そのものではなく、規律を欠いた実践への評価です。JSTQB用語集は、アドホックテストを「テスト設計技法を用いず、非公式に、事前の期待結果の定義なしに行うテスト」と定義しています。正確な用語は一次資料で確認しておくと、社内説明の説得力が増します。

• JSTQBのシラバスで用語定義を確認する
• James Bachによる探索的テストの解説を読む（英語）

場当たり的テストと探索的テストを分けるのは「規律」です。

観点	アドホックテスト	探索的テスト
規律	欠けやすい	計画・記録・報告の型がある
焦点	不明確になりがち	チャーターで狙いを固定
スキル	前提としない	経験と着眼点を要する
再現性	残りにくい	記録により追試・引き継ぎ可能

この記事で扱う4ステップの全体像

本記事では、探索的テストを次の4ステップに分解して手順化します。

1. 計画：チャーターを書き、偵察に投資する
2. 実行：タイムボックスで集中し、攻めの切り口で狙い撃つ
3. 記録：事象・操作・疑問をその場で残す
4. 報告・振り返り：デブリーフィングで共有し、次につなげる

以降のセクションで、それぞれを実例とフォーマット付きで掘り下げます。

ステップ1：計画｜チャーターを書き、偵察に先行投資する

探索的テストの進め方でつまずく最大の原因は、計画を飛ばしていきなり画面を触り始めることです。これでは手当たり次第と変わりません。

計画フェーズの成果物は2つあります。狙いを1枚に固定する「チャーター」と、対象を先に掴む「偵察」です。

チャーターの実例：1枚で”何を・なぜ探すか”を固定する

チャーターとは、そのセッションで「何を・なぜ探すか」を1枚にまとめた指針です。長文の仕様書は不要で、次の項目が埋まれば十分です。

` 【チャーター例】 対象 ： 会員登録〜初回ログインまでの一連フロー 狙い ： 入力値と状態遷移の異常系に想定外がないか探る リスク仮説： 途中離脱・二重送信・戻る操作で不整合が起きそう 使うデータ： 正常系1件／境界値（最大文字数）／全角・絵文字 時間枠 ： 60分（準備時間を除く） `

このように狙いを言語化しておくと、探索が脱線しにくくなります。高橋寿一『知識ゼロから学ぶソフトウェアテスト』でも、探索的テストのサンプル手順として「クライテリア（判断基準）を決めてからタスクを実行する」という流れが示されています。何を良しとするかを先に決めることが、質のブレを抑えます。

偵察フェーズ：対象の構造とデータの流れを先に掴む

弊社が支援したテスト代行の案件では、テスト開始時に対象の全体像を把握しきれておらず、本来1回で確認できることに何度も画面を行き来し、余計な時間を費やした経験があります。偵察を先に済ませた案件では、同じ確認でも画面往復の無駄が目に見えて減り、探索に使える時間が増えました。

そこで得た教訓が「急がば回れ」です。偵察、すなわち対象の構造・データの流れ・業務上の位置づけを先に掴むことに投資すると、結果として作業総量が減ります。

全体像の把握への先行投資が、結果的にトータルの時間を短縮します。

偵察は具体的には「画面マップ」を1枚作る作業です。次の手順で進めると、抜けが起きにくくなります。

1. 入口となる画面（ログイン・一覧・ダッシュボード等）から順に開いていく
2. 各画面で「画面名／入口・出口／扱うデータ／関連する機能」の4点をメモする
3. 遷移先を1つずつたどり、行き止まりや分岐（エラー画面・確認画面）も書き足す
4. 一巡したら、データが生成・保存・表示される場所を線でつなぐ

こうして偵察で確認したい観点をまとめると、次のようになります。

• 画面遷移の全体マップ（どこから来て、どこへ抜けるか）
• データがどこで生成され、どこに保存・表示されるか
• その機能が業務のどの局面で使われるか（利用者の期待値）

なお偵察は効率化のための工夫であり、探索そのものが対象理解の浅い段階から機能する学習手段である点は変わりません。マップが未完成でも、動かしながら地図を描き足していく姿勢が探索的テストの本質です。

重要度・リスク・確認容易性で順位づけする

テスト項目を列挙するだけでは、テスト設計は完成しません。列挙した項目を、重要度・リスク・確認容易性の3軸で順位づけするまでが設計です。

評価軸	問い	優先度への影響
重要度	壊れると業務・信用に直結するか	高いほど先に
リスク	過去に不具合が多い／複雑か	高いほど先に
確認容易性	短時間で観察できるか	高いものを差し込む

限られた工数で「バグが出やすい箇所」に絞り込むための、実務的な物差しになります。

ステップ2：実行｜タイムボックスと「攻めの切り口」

計画が整ったら、いよいよ実行です。ここでの規律は「タイムボックス」と「攻めの切り口」の2つです。

タイムボックス：60分で区切る理由と時間枠外の別勘定

探索的テストは、だらだら続けると集中力も観察の質も落ちます。そこで1セッションを45〜90分、目安60分のタイムボックスで区切ります。

60分という単位には業務上の合理性があります。人の集中力が高い密度を保てるのがおおむねこの範囲であること、そして準備・記録まで含めても半日に複数セッションを組みやすい運用単位になることです。SBTMでは90分前後を標準とすることが多いですが、兼任チームでは60分から始めるほうが日々の業務に差し込みやすいでしょう。

区切りがあることで「この時間内でこのチャーターを攻めきる」という集中が生まれます。長すぎず短すぎない60分前後が、多くのチームで扱いやすい単位です。

準備の時間はタイムボックスの外で別勘定にします。テストデータの投入や環境設定に要する時間をセッション時間に含めると、実際の探索時間が目減りしてしまうためです。準備は準備として、別枠で見積もります（この別勘定は始めやすさを優先した本記事流のアレンジで、原典SBTMとの関係は後述します）。

「20の扉」：回数制限があるから前の答えが効く

なぜ、あらかじめ全ケースを作らずに探索するのが効くのか。Copeland『はじめて学ぶソフトウェアのテスト技法』は、Bach による「20の扉」の比喩でこれを説明します（by Bach）。

「20の扉」とは、Yes/Noで答えられる質問を20回だけ使って正解を当てるゲームです。質問回数に上限があるからこそ、前の答えを見てから次の質問を決めることが効いてきます。

もし20問を最初に全部作ってしまうと、前の回答を活かせず非効率になります。探索的テストも同じで、直前の結果から次の一手を組み立てるからこそ、限られた工数で深く攻められるのです。

攻めの切り口カタログ：異常系・境界を狙い撃つ

「どこを攻めればいいか分からない」という属人性は、切り口をカタログ化することで緩和できます。James Whittaker『How to Break Software』は、不具合のタイプと、それを引き出す攻撃（アタック）操作をペアで整理しています（by Whittaker）。

なお、こうした攻撃をまとめた「フォールトアタック」という呼称は、ISTQB/JSTQBの用語集でも attack（fault attack）として定義されています。

抽象的な操作名だけでは自社画面に落とし込みにくいため、会員登録フォーム・EC決済・業務系フォームなど身近な題材での操作例を添えます。非エンジニアのメンバーでも、この粒度なら手を動かせます。

狙う欠陥タイプ	攻撃操作の例	身近な画面での具体操作例
入力境界	入力バッファをオーバーフローさせる	氏名欄に256文字を貼り付ける／備考欄に長文をペースト
初期値の扱い	デフォルト値を固定化させて挙動を見る	日付が今日のまま／都道府県が初期選択のまま送信
エラー処理の不備	エラーメッセージを強制的に表示させる	決済画面で必須項目を空にして進む／通信を切る
データ構造	過少・過多の値を与える	数量に0や999999／金額欄にマイナス値を入れる
計算・集計	計算結果を過大・過小に振らせる	数量に大量値を入れ合計が桁あふれしないか見る
異常系網羅	エラー処理コードをすべて実行させる	二重送信・戻る操作・タイムアウト後の再送を試す

これらは「バグが出やすい箇所に絞る」ための着眼点です。ベテランが無意識に狙っている場所を、こうして言語化すればチームで共有できます。

この切り口カタログは、自社のバグ傾向に合わせて育てる前提の”生きた資料”です。リリース後に出た不具合を振り返り、「どの切り口で見つけられたはずか」を1行追記していくと、自社の弱点に沿ったチェック観点へ育っていきます。決済まわりで漏れが多いなら決済の行を厚く、入力系で多いなら境界値の例を増やす。汎用カタログを起点に、案件特有の攻め筋を継ぎ足していくことで、切り口は年々鋭くなります。

ステップ3：記録｜属人性を消すフォーマット

探索的テストが「担当者スキル頼み」に見える最大の理由は、頭の中の探索が外に残らないことです。記録の型を持つことが、属人性を消す核心になります。

探索的テストの進め方で最も差がつくのは、この記録の徹底です。動かした本人しか経緯を知らない状態を、誰でも追試できる状態へ変えていきます。

その場で残す3点：事象・操作・疑問

記録は後回しにすると必ず抜けます。セッション中、その場で残すべきは次の3点です。

• 事象：何が起きたか（期待と違う挙動・気になる表示）
• 操作：直前にどんな操作をしたか（再現の手がかり）
• 疑問：仕様として正しいか判断がつかない点・後で追試したい点

記録フォーマット例：後から追試・再現できる粒度

以下のようなフォーマットを1枚用意しておくと、記録の粒度が揃います。

時刻	操作	事象	期待との差	疑問・要追試	スクショ
10:12	最大文字数＋1で登録	エラー無しで送信	弾かれるべき	上限バリデーション有無	有
10:20	戻る→再送信	二重登録された	抑止されるべき	トークン制御の仕様確認	有

再現手順が伝わる粒度で残すことが肝心です。バグとして起票する段になっても、この記録がそのまま材料になります。書き方の型は再現手順が伝わるバグ票の書き方を確認すると合わせて整えると効果的です。

記録がベテランの勘をチームの資産に変える

記録があるからこそ、ベテランの着眼点がチームの資産になります。

「なぜそこを触ったのか」という意図が疑問欄に残れば、経験の浅いメンバーは次回それを真似できます。暗黙知だった勘や着眼点が、引き継ぎ可能な観点リストへと変わっていくのです。

実際、弊社が支援したテスト代行の案件でも、記録フォーマットを1枚残しておいたことで、担当交代時の引き継ぎがスムーズになりました。前任者が何を見て何を残したかが1枚で伝わるため、後任は探索の続きから着手できます。

こうした属人化の解消は記録だけで完結するものではありません。体制面まで含めた整理は、テストの属人化を4層で解消する方法を確認するを参考にしてください。

ステップ4：報告・振り返り｜デブリーフィングとSBTM

セッションをやりっぱなしにしないための最後のステップが、報告と振り返りです。ここを回せるかどうかで、探索の質が継続的に上がるかが決まります。

デブリーフィング：終了後15分で”見た/見ていない”を共有

セッション終了後、10〜15分のデブリーフィング（振り返りの共有）を行います。目的は「何を見たか」「何が未確認か」をチームで言語化することです。

デブリーフィングで必ず聞く問いを、テンプレート化しておきましょう。

• チャーターの狙いはどこまで達成できたか
• 気になった事象・未起票の疑問は何か
• 触れなかった領域・時間切れになった領域はどこか
• 次に優先して攻めるべき箇所はどこか

SBTM：チャーター単位で探索を束ね進捗を可視化

個々のセッションを組織的に束ねる枠組みが、セッションベースドテストマネジメント（SBTM）です。SBTMは Jonathan Bach / James Bach によって提唱されました。

SBTMでは、チャーター（対象・狙いを1枚に書いたもの）を単位として探索を管理します。1チャーター＝1タイムボックスを基本に、消化したチャーター・残ったチャーターを並べれば、兼任チームでも探索の進捗と抜け漏れが一目で分かります。

SBTMの構成要素	中身	時間の目安
チャーター	対象・狙いを1枚に	事前作成
タイムボックス	集中して探索	45〜90分（目安60分）
記録	事象・操作・疑問をその場で	セッション中
デブリーフィング	見た/未確認を共有	終了後10〜15分

なお、正典のSBTM（Jonathan Bach）では、セッション時間を「テスト設計・実行／バグ調査・報告／セットアップ」の3要素（TBSメトリクス）に分解し、準備（セットアップ）の時間もセッション内の割合として記録します。本記事では始めやすさを優先して準備を別枠に置いていますが、運用に慣れてきたら、準備をセッション内の割合として計上する方式に切り替えると、より原典に沿った管理になります。

複数セッションを束ねる週次運用の回し方

セッションが増えてくると、1枚ずつの記録だけでは全体像が見えなくなります。そこで「チャーター一覧シート」を1枚用意し、各チャーターを「消化済み／残り／未着手」の状態で並べて管理します。

週次の回し方は、次のようなリズムが現実的です。

• 週の初めに、その週に消化するチャーターを一覧から3〜5枚選ぶ
• 各セッション後、シートの状態を「消化済み」に更新し、気づきを1行足す
• 週末に一覧を見返し、未着手・時間切れのチャーターを翌週へ繰り越す
• デブリーフィングで出た新しい未確認領域を、新規チャーターとして一覧に追加する

兼任チームでは、この更新をデイリーの短い共有やタスク管理ツールに載せると、専任担当がいなくても抜け漏れが可視化されます。1枚のシートが「探索のバックログ」として機能し、進捗と残量が誰の目にも見える状態になります。

未確認領域の棚卸しが次セッションのチャーターになる

デブリーフィングで洗い出した「未確認領域」は、そのまま次のセッションのチャーターの種になります。この循環が生まれると、探索は行き当たりばったりから計画的な積み上げへと変わります。

高橋寿一『知識ゼロから学ぶソフトウェアテスト』は、アジャイルやAIを活用する時代においても探索的テストが重要な位置を占めると述べています。反復開発では仕様が動き続けるため、ケースを固め切れない領域を人の学習で補う探索的テストの価値が、むしろ高まっているといえます。

報告が整えば、上司やクライアントへ「どこを・どれだけ・何のために確認したか」を説明できます。費用対効果の説明責任にも、この記録と報告が直結します。

テストケースベースとの併用・使い分け（置き換えでなく補完）

ここまで読んで「では既存のテストケースは捨てるのか」と不安になった方もいるでしょう。答えは明確です。

探索的テストはテストケースの置き換えではなく補完です。

ケースベースが得意なこと・苦手なこと

テストケースを早い段階で作り込む方式には、明確な長所と短所があります。仕様が固まった規定の網羅は得意ですが、設計を早期に固定するぶん、後から判明した観点を取り込みにくいという弱点があります。

また、同じテストケースを繰り返し実行するだけでは、新しい不具合は見つかりにくくなります。既に通った道を何度歩いても、未知のバグには出会えないためです。

探索的テストが補完する「想定外の操作」

一方の探索的テストは、対象を動かしながら気づきを得るため、事前に想定しきれなかったバグに到達しやすいという特性があります。網羅したはずなのに想定外の操作で出るバグ、暗黙の期待値や異常系の抜けは、まさに探索が得意とする領域です。

規定の網羅はケースベースで担保し、想定外・異常系は探索的テストで攻める。この役割分担が現実的です。

観点	テストケースベース	探索的テスト
目的	規定要件の網羅的確認	想定外・異常系の発見
得意領域	仕様が固まった機能	仕様が曖昧・変化する領域
属人性	低い（手順が明文）	記録により低減できる
記録	ケースが最初からある	セッション中に生成
向く場面	回帰・受け入れ	リリース前の追い込み

両者を1つのテスト計画にどう組み込むか

実務では、1つのテスト計画の中に両者を並べます。まずケースベースで基盤を固め、その上に探索的テストのセッションを差し込む構成です。ケース設計そのものの手順はシステムテストケースの作成手順を確認するで体系立てて確認できます。

少人数・兼任チームでの探索的テストの進め方

最後に、テスト専任がいない前提での現実的な回し方を整理します。少人数・兼任チームにこそ、この手法は効いてきます。

専任ゼロでも回る「60分×1チャーター」から始める

いきなり全面導入を狙う必要はありません。1案件につき1〜2セッションから始めれば十分です。

専任がいなくても「60分×1チャーター」から始められます。チャーター1枚と記録フォーマット1枚があれば、兼任の開発エンジニアでも今日から回せます。

人数別の現実解は、次のように使い分けます。

• 1人運用：記録の負荷を下げるため、画面操作を録画しつつ要点だけメモに残す。デブリーフィングは開発リーダーと5分だけでも成立する
• 2〜3人運用：探索役と記録役を分けると、その場記録の抜けが減る。終了後に15分の相互共有を挟む
• チーム運用：チャーター一覧シートを共有し、週次で消化状況を棚卸しする

工数の見積りと費用対効果の説明のしかた

チャーターとタイムボックスがあると、工数が予測可能になります。「準備30分＋探索60分＋振り返り15分」といった形で、案件あたりの投入時間を上司に提示できます。

費用対効果は、次のような観点で説明すると通りやすくなります。

• 記録により属人化が減り、引き継ぎコストが下がる
• 本番バグの流出を抑え、クライアントの信頼低下を防ぐ
• 少ない工数を「バグが出やすい箇所」に集中投下できる

リリース直前に間に合わせない：計画的にセッションを差し込む

探索的テストを「リリース直前の駆け込み」で使うのは避けたいところです。計画的に、開発の節目ごとにセッションを差し込むことで、品質担保と納期を両立させます。

明日から始める最小構成は、次のチェックリストで確認できます。

• チャーターを1枚書く（対象・狙い・リスク仮説・データ・時間枠）
• 準備時間を別勘定にし、探索を60分で区切る
• 事象・操作・疑問をその場で記録する
• 終了後15分でデブリーフィングし、未確認領域を書き出す
• 未確認領域を次回チャーターに引き継ぐ

リリース後の流出を体制面から減らす取り組みは、リリース後のバグを減らす体制の作り方を読むも併せて検討してください。

4ステップで振り返る｜勘を仕組みにするために

規律ある4ステップとして、探索的テストの手順を解説してきました。最後に全体を振り返ります。

• 計画：チャーターで狙いを固定し、偵察に先行投資する。列挙で終わらせず順位づけまで行う
• 実行：45〜90分（目安60分）のタイムボックスで集中。準備は別勘定にし、攻めの切り口で狙い撃つ
• 記録：事象・操作・疑問をその場で残し、属人性を消す
• 報告・振り返り：デブリーフィングとSBTMで、見た/未確認を可視化し次へつなぐ

背骨は一貫しています。手当たり次第との違いは「規律」です。この規律があるからこそ、経験の浅いメンバーでも一定の質を出せ、ベテランの着眼点をチームの資産にできます。

まずは1案件、チャーター1枚から。明日から1セッション回してみることが、社内テスト体制強化の第一歩になります。

テスト体制の見直しや探索的テストの導入を検討されている方は、少人数チームのテスト体制づくりを相談するからお気軽にご相談ください。

探索的テストの実践に関するよくある質問

Q1. 探索的テストとアドホックテストの違いは何ですか。

探索的テストはスキルと経験を要する規律ある活動で、手当たり次第のアドホックテストとは対極にあります。チャーターで狙いを固定し、記録と振り返りで再現性を担保する点が決定的な違いです。無計画に触るのではなく、学びながら次の一手を計画的に選びます。

Q2. 1セッションの時間はどのくらいが適切ですか。

1セッションは45〜90分、目安60分のタイムボックスで区切るのが適切です。集中力が保て、前の結果を次に活かす探索のリズムが生まれる長さだからです。テストデータ投入や環境設定などの準備時間は、この枠に含めず別勘定にします。

Q3. テストケースは作らなくてよいですか。

いいえ、探索的テストはテストケースの置き換えではなく補完です。仕様が固まった規定要件はケースベースで網羅し、想定外の操作や異常系を探索的テストで攻める、という役割分担が現実的です。両者を1つのテスト計画に組み込んで運用します。

Q4. 専任QAがいなくても本当に回りますか。

専任QAがいなくても、少人数の兼任チームで探索的テストは回せます。1人運用のときは画面操作を録画しつつ要点だけメモに残して記録負荷を下げ、デブリーフィングは開発リーダーと5分だけでも成立します。まずは「60分×1チャーター」から、次のように始めると無理がありません。

• チャーターと記録フォーマットを各1枚だけ用意する
• 探索を60分で区切り、準備は別勘定にする
• 終了後は短時間でも「見た/未確認」を口頭共有する

Q5. 探索的テストで見つけたバグはどう扱いますか。

探索的テストで見つけた事象は、記録フォーマットからバグ票へ橋渡しして扱います。セッション中に残した「操作・事象・期待との差」がそのまま再現手順の材料になるため、起票の手戻りが減ります。判断がつかない疑問は、いったん「要追試」として残し、デブリーフィングで仕様確認の可否を切り分けます。