exploratory-testing

スクリプト化されたテストでは見つけられないバグを発見する、体系的な探索です。探索的テストでは、学習、テスト設計、実行を同時に行います。テスターはアプリケーションが明らかにする内容に応じて、リアルタイムで探索方法を調整します。このスキルでは、探索を体系的かつ再現可能にし、記録に残せるようにするためのフレームワークを提供します。

---

すぐに使う

状況に合ったチャーターパターンと、参照するセクションを確認してください。

状況	チャーターパターン	参照先
新機能 — 機能を理解し、要件の不足を見つける	「さまざまなロールやデータを使って［機能］を探索し、要件の不足や予期しない動作を発見する」	session-templates.md のチャーター例とセッションの流れ、heuristics-and-automation.md の境界値／「もしも」チェックリスト
リグレッション — 変更が反映されたばかり	「［変更］後の［領域］を探索し、統合ポイントでのリグレッションを発見する」	heuristics-and-automation.md の状態遷移ヒューリスティック
バグ調査 — あいまいな報告（「ときどき遅い」など）	「報告された［条件］で［領域］を探索し、正確な再現手順を見つける」	session-templates.md のセッションの流れとセッションログテンプレート、heuristics-and-automation.md のエラー処理ヒューリスティック

各行の詳しい時間配分は、下記の状況別のセッション計画を参照してください。

---

発見に向けた質問

セッションを設計する前に、背景情報を集めます。まず .agents/qa-project-context.md を確認してください。ファイルが存在する場合は、その内容を基礎として使い、すでに回答されている質問は省略します。

対象領域

• 探索の対象となる機能、モジュール、またはフローは何ですか？
• 新機能（発見モード）ですか、それとも既存の機能（リグレッションモード）ですか？
• この領域に加えられた最新の変更は何ですか？
• 既知のリスク領域や、過去にバグが集中した箇所はありますか？（リスクデータについては risk-based-testing を参照してください。）

仮説と懸念点

• 何が壊れると思いますか？（直感も有効な出発点です。）
• 開発者が難しい、または不確かだと言っていた点は何ですか？
• 自動テストスイートでカバーされていない領域はありますか？
• この領域について、過去にユーザーから問題が報告されたことはありますか？

時間と範囲

• このセッションに使える時間はどのくらいですか？（45〜90分が最適です。）
• 広く調査する（範囲を広く取る）のか、深く掘り下げる（1つの領域に絞って集中的に調査する）のか、どちらですか？
• どの環境とデータセットを利用できますか？
• 対象にしたい特定のプラットフォーム、ブラウザー、またはデバイスの種類はありますか？

チームの状況

• この機能を開発したのは誰ですか？（探索中に開発者とペアを組むと、大きな効果が得られる場合があります。）
• この領域の専門知識を持つテスターはいますか？
• セッションレポートの送付先は誰ですか？

---

基本原則

1. 体系的な自由

探索的テストは、「あちこちをクリックして、何が起きるか見る」ことではありません。対象、リソース、情報目標を定めたチャーターに沿って進めます。そのチャーターの範囲内では、テスターは手がかりを追い、異常を調査し、発見に応じて方向を変える自由があります。体系性によって再現可能になり、自由度によって効果的になります。

2. 進めながら記録する

記録されていない観察結果は、失われたも同然です。セッション後ではなく、実施中にメモを取ってください。何をしたか、何を見たか、どのような疑問が生じたかを記録します。成果物はセッションログです。テストスクリプトの代わりになります。

3. スクリプトよりヒューリスティック

ヒューリスティックは、正確な手順を指定せずに探索を導く思考ツールです。以下の HICCUPS と FEW HICCUPS は、ソフトウェアを検証するための体系的な視点を提供します。より良い質問を促し、見過ごしてしまうことに気づく助けとなります。

4. 時間を区切ったセッション

終わりのない探索では、次第に効果が薄れていきます。90分を過ぎると、疲労によってバグ発見の効果が低下します。セッションは45〜90分に区切り、その後に振り返りを行ってください。長時間で焦点の定まらないセッションより、短時間で焦点を絞ったセッションのほうが効果的です。

5. 見つけたバグは終わりではなく、始まりです

バグを見つけた探索セッションは、作業の半分しか終えていません。もう半分は、そのバグを自動テストで検出できたかどうかを考えることです。可能であれば、そのテストを書きましょう。探索的テストは自動化パイプラインに活用されます。

---

セッションベーステスト管理（SBTM）

SBTM は、探索的テストに管理レイヤーを追加します。チャーターで目的を定め、セッションを作業単位とし、デブリーフで学びを抽出します。

標準的な参考資料：

• SBTM PDF（Jon Bach / James Bach、satisfice.com）— https://www.satisfice.com/download/session-based-test-management
• Taking Testing Seriously: The Rapid Software Testing Approach（Bach & Bolton、Wiley 2025）— 現在の RST/SBTM の権威ある書籍です。
• HTSM v6.3（Bach、最終更新 2024 年 12 月）— 状態ベーステストと境界ヒューリスティックを重視しています。以下の HICCUPS と組み合わせてください。

チャーターテンプレート

チャーターは、次のパターンに沿った 1 文のミッションステートメントです。

Explore [target]
  with [resources]
  to discover [information]

チャーターの品質チェックリスト：

• 探索の指針となるだけの具体性がある対象であること（「アプリを探索する」では不十分です）
• 使用する具体的なツール、データ、または条件がリソースに記載されていること
• 情報目標には、証明したいことではなく、知りたいことが記載されていること
• 1 回のセッションで 45～90 分以内に無理なくチャーターを達成できること

チャーターの例を 5 つ（チェックアウト、プロフィール、検索、データエクスポート、複数ユーザーでのコラボレーション）記載した references/session-templates.md を参照してください。

セッションの準備、進行、デブリーフ

セッションのライフサイクル全体、つまりセッション前の準備手順、環境準備チェックリスト、分単位のセッション進行、興味深いことを見つけたときのループ、構造化されたデブリーフテンプレートは、references/session-templates.md に記載されています。セッションの開始時に開き、表示したままにしてください。

参考資料を開かなくても覚えておくべき時間配分の目安：最初の 15 分で状況を把握して調査し、約 40 分間探索し、最後にまとめてデブリーフを行います。1 人で行う場合でも、必ずデブリーフを実施してください。

---

バグ発見のヒューリスティック

ヒューリスティックとは、探索の指針となるメンタルモデルです。すべてを網羅的に確認するためのチェックリストではなく、物事を見るための視点です。

HICCUPS

バグを明らかにする 7 つのオラクルを覚えるためのニーモニックです。オラクルとは、問題を認識するための原則です。

文字	オラクル	確認すること	質問の例
H	履歴	現在の動作は過去の動作と一致していますか？	直近のリリースでは動作していましたか？動作に微妙な変化はありましたか？
I	イメージ	製品のブランドと品質基準に合っていますか？	洗練された見た目ですか？アプリのほかの部分と一貫性がありますか？
C	比較対象	類似製品ではどのように対応していますか？	競合製品ではどうなっていますか？業界標準は何ですか？
C	主張	約束された内容と一致していますか？	仕様と一致していますか？マーケティングページとは？ツールチップの文言とは？
U	ユーザーの期待	実際のユーザーがこれをわかりにくい、または不満に感じるでしょうか？	母はこれを理解できますか？パワーユーザーはいら立ちますか？
P	製品	同じ製品のほかの部分との一貫性がありますか？	このエラーメッセージは、ほかのエラーメッセージのスタイルと一致していますか？
S	標準	該当する標準に準拠していますか？	アクセシビリティについては WCAG、プロトコルについては RFC、データの取り扱いについては GDPR に準拠していますか？

FEW HICCUPS（拡張版）

基本の HICCUPS モデルに、3 つの視点を追加します。

文字	オラクル	確認すること
F	慣れやすさ	初めて使うユーザーでも、助けを借りずに理解できますか？
E	説明可能性	その動作をほかの人に説明できますか？説明できない場合、バグかもしれません。
W	現実世界	現実の環境でも動作しますか？（異なるロケール、タイムゾーン、ネットワーク状況、画面サイズ）

ヒューリスティックなテストアイデア集

境界値、状態遷移、エラー処理、「もしも」の探索に関する詳細なテストアイデアの一覧は、references/heuristics-and-automation.md にあります。具体的なプロンプトが必要なときに参照してください。

• 境界値のヒューリスティック — 数値、文字列、時刻、コレクションの境界（ゼロ／1／複数、最大値±1、Unicode、DST、ページサイズの境界）。
• 状態遷移のヒューリスティック — 手順のスキップ、前の状態への復帰、中断、繰り返し、並行する遷移、エラー発生後の状態。
• エラー処理のヒューリスティック — ネットワーク切断、不正なレスポンス、レート制限、期限切れのセッション、無効なアップロード。
• 「もしも」のシナリオ — 戻るボタン、重複したタブ、広告ブロッカー、書式付きテキストの貼り付け、アクセシビリティ機能、馴染みのないロケール、悪意のあるユーザー。

---

メモ作成用テンプレート

セッションログを使って、観察内容をリアルタイムで記録してください。セッションログの表形式と観察タグ（BUG、QUESTION、IDEA、RISK、NOTE）は、references/session-templates.md にあります。すべての観察内容に一貫したタグを付けることで、ログ全体を読み返さなくても、振り返り時に調査結果を分類できます。

---

探索する場合と自動化する場合

すべてのテストが探索的テストに適しているわけではなく、すべてのテストが自動化に適しているわけでもありません。次の判断基準を使ってください。

探索する場合：

• 機能が新しく、要件がまだ変化している
• 曖昧なバグ報告（「ときどき遅い」など）を調査している
• 領域全体の品質を評価したい（品質調査）
• 状態の組み合わせが多く、スクリプトでの自動化が難しい複雑な領域である
• 主観的な品質（UX、直感的に使えるか、見た目の仕上がりなど）を評価する必要がある
• 動作を確認するのではなく、バグを見つけようとしている

自動化する場合：

• 動作が安定していて、明確に定義されている
• すべてのコミット／PRでテストを実行する必要がある（回帰テスト）
• シナリオに明確な合格／不合格の基準がある
• 手作業での探索が煩雑なデータの組み合わせを扱う
• 大規模なクロスブラウザーまたはクロスデバイスのカバレッジが必要である
• 探索で見つけたバグの再発を防ぎたい

探索から自動化へのパイプライン

探索で見つかった再現可能なバグはすべて、自動化された回帰テストにする必要があります。そうすれば、今後のセッションで古いバグを再確認する代わりに、新しい領域に注力できます。パイプライン全体の図、変換手順、実例としての Playwright 回帰テスト（BUG-456 のメール検証）については、references/heuristics-and-automation.md を参照してください。

探索的なスモークテストのチャーターが安定したら（「ハッピーパスが引き続き動作するかどうか」）、一度に自動化するのではなく、2段階で進めてください。まずチャーターを自然言語によるゴール実行として agentic-browser-testing に渡し、スクリプトを書かずにフローが安定していることを確認します。次に、保守対象のセレクターを持つに値するほど安定したフローを、スクリプト化した playwright-automation テストに昇格させます。

---

コンテキスト別のセッション計画

コンテキスト	焦点	チャーターパターン	時間配分
新機能	学習、要件の不足、UX	「さまざまなロール／データを使って［機能］を探索し、要件の不足や予期しない動作を見つける」	状況把握15分＋ヒューリスティック40分＋境界値／エラー20分＋記録15分
回帰	変更とその副作用	「［変更］後に［領域］を探索し、統合ポイントでの回帰を見つける」	差分の確認10分＋変更領域20分＋統合20分＋スモークテスト15分＋記録15分
バグ調査	再現と条件の絞り込み	「［報告された条件］で［領域］を探索し、正確な再現手順を見つける」	報告の確認10分＋再現15分＋条件の絞り込み20分＋関連領域15分＋記録15分

---

支援を受けながら探索する（LLMは代替ではなく伴走者）

重要な思考の主導権を保ちながら、LLMをオラクル兼アイデアジェネレーターとして使うセッションを実施できます。これは、Bach & BoltonのTaking Testing Seriously（Wiley 2025）におけるテストとチェックの区別にうまく当てはまります。LLMはチェック（既知の参照情報と一致しているか？）を支援できますが、テスト、つまり何を探索し、何を問題と見なすかについての人間の判断は、あなた自身が担います。うまく使えば、LLMはチャーターのカバレッジを広げます。使い方を誤れば、あなたの判断を自信に満ちた幻覚に置き換えてしまいます。

セッション中にLLMを使う方法：

• セッション前のアイデアジェネレーターとして。 チャーターを貼り付け、ヒューリスティックでは見落とす可能性のあるエッジケースを10個挙げるよう依頼します。実際に試すものを3個選びます。残りは破棄してください。大半は一般論か、作り話です。
• セッション中の「これは正しいのか？」を確認するオラクルとして。 予想外の動作を見つけたら、仕様書／API／標準を調べるようエージェントに依頼します。引用された情報源と照合せずに、回答を信頼してはいけません。
• 発見事項のファクトチェッカーとして。バグ報告の執筆者としてではありません。 バグ報告はあなたが書き、LLMには明確さを確認してもらいます。逆のやり方、つまりLLMが書いてあなたが確認する方法では、テンプレートどおりの報告になり、人間が気づいた具体的な詳細が失われます。
• デブリーフ中のカバレッジの抜けに関する提案に。 「このメモを踏まえると、次にどのチャーターを実行すべきでしょうか？」

生産性のパラドックスに関する警告： AIツールは、テスターの成果が一見速くなったように見せながら、価値を生み出していた批判的思考をひそかに損なうことがあります。（Michael BoltonはDevelopSenseの講演や投稿でこの主張を展開しています。引用された知見ではなく、実践上の原則として受け止めてください。）デブリーフのメモがLLMの書いたもののように聞こえ始めたら、主導権はすでにLLMに移っています。いったん止め、次のセッションは支援なしで実施してください。

LLMに決して委ねてはいけないこと：

• 何を探索するかを選ぶこと。チャーターは、リスクとステークホルダーの懸念に対するあなた自身の理解に基づいて作成する必要があります。
• 何かがバグかどうかを判断すること。「モデルは問題なさそうだと言っています」はデブリーフではありません。
• テストの経緯を書くこと。具体的で状況に即した詳細こそが探索的テストの要点です。一般的なLLMの文章は、その正反対です。

（AIを使ってテストするのではなく）AI機能そのものをテストする方法については、ai-system-testingを参照してください。

---

現代のチームにおけるテスターの役割

人員配置や、自身の役割について話し合う際に役立つ用語です。これらは業界でよく見られる類型であり、正式な分類体系ではありません。

• 組み込み型テスター — 独立したゲートとして振る舞うのではなく、開発に関する会話に最初から最後まで参加する、デリバリーチームに完全に組み込まれたテスターです。部門横断型チームで最も一般的なモデルです。
• 専門テスター — セキュリティ、アクセシビリティ、パフォーマンスなど、ある領域の高度なスキルを持ち、複数のチームから依頼を受けます。
• コーチ型テスター — ヒューリスティック、チャーターの作成、探索的思考といった技術を開発者や若手テスターに教えるシニアテスターです。自身がエンドツーエンドでテストすることはほとんどありません。

組織が組み込み型テスターへ移行しているなら、探索的テストは実力を示すうえで最も効果の大きいスキルの一つです。コーチングなしに開発者が習得するのは難しく、テストの考え方が最も明確に表れる分野です。

テストとチェックの区別、およびAIの役割について詳しくは、「What Is Testing? A Conversation with Bach and Bolton」（DevelopSense、2026年2月）を参照してください：https://developsense.com/blog/2026/02/what-is-testing-a-conversation-with-james-bach-and-michael-bolton

---

アンチパターン

チャーターなしの探索

チャーターを用意せずに探索することです。「適当に触って、何が見つかるか見てみます」では、結果に一貫性がなく、再現もできず、意味のあるデブリーフもできません。たとえ一文でも、必ずチャーターを書いてください。

セッションが長すぎる

3時間に及ぶ探索セッションを実施することです。バグを発見する効果は、90分を過ぎると急激に低下します。疲労によってテスターは問題を見落とし、手がかりを追うのをやめてしまいます。長時間のテストは、休憩を挟んだ60〜90分のセッションを複数回行う形に分割してください。

セッション中にメモを取らない

何が起きたかを思い出すのに記憶だけを頼りにすると、セッションが終わる頃には、観察したことの半分を忘れ、残りも曖昧になっています。上記のテンプレートを使って、リアルタイムでメモを取りましょう。

うまくいくケースだけを探る

探索的テストを、正常に動作することの確認だけに使っています。これは自動テストですでにカバーされている内容と重複します。探索的テストの強みは、誰もスクリプト化を考えていなかった経路で問題を見つけることです。ヒューリスティックを使って、あえて不慣れな領域にも踏み込みましょう。

自動化への変換を行わない

自動テストを書かなかったため、リリースのたびに同じバグを手作業で見つけています。探索を通じて見つけた再現可能なバグは、すべて自動化された回帰テストにする必要があります。探索から自動化へのパイプラインを機能させましょう。

探索を「本当のテスト」ではないと扱う

探索的テストは、スクリプト化されたテストより厳密さに欠けると考えています。チャーター、セッションログ、デブリーフを用いる SBTM では、記録に残り、説明責任を果たせるテストを実施できます。ドキュメントの形式はテストスクリプトとは異なりますが、厳密さは同等です。

---

検証

セッションで、単に「テストした」という感覚だけでなく、実際に説明責任を果たせる成果物が作られたことを証明します。まずは最小限の確認から始めましょう。

• 各チャーターが実際のチャーターであること： すべてのセッションに、対象が「アプリ」より具体的な Explore [target] with [resources] to discover [information] という行が記述されています。チャーターの行がないセッションは、チャーターのない探索であり、SBTM ではありません。
• セッションログにタイムスタンプとタグがあること： ログを開き、観察記録に時刻の列とタグ（BUG、QUESTION、IDEA、RISK、NOTE）が付いていることを確認します。時刻もタグもない散文の羅列では、デブリーフを行えません。
• 報告されたすべてのバグがチャーターにひも付き、再現できること： 各バグ ID について、クリーンな環境で再現手順を実行し、今も発生することを確認します。再現できないバグは、報告済みの不具合ではなくメモです。
• 回帰テストに変換されたものが、実際に失敗してから成功すること： 探索で見つけた問題を自動化に移した場合は、新しいテストをバグのあるビルド（npx playwright test path/to/spec が失敗するはずです）と修正後のビルド（成功するはずです）の両方で実行します。失敗するところを一度も確認していない回帰テストでは、そのバグを確実に検出できるとは証明されていません。
• カバレッジが正直に記載されていること： デブリーフでは、各チャーターの領域を「カバー済み」「一部カバー」「未探索」のいずれかで示します。その下に未探索の領域が記載されているのに「100% カバー済み」とするのは、見つけるべきギャップです。

完了条件

• 各対象領域についてセッションチャーターが作成され、それぞれが「Explore [target] with [resources] to discover [information]」の形式に従っている
• 計画したすべてのセッションを実施し、デブリーフテンプレートを使ってデブリーフを行い、各チャーターの領域を「カバー済み」「一部カバー」「未探索」のいずれかで示している
• セッション中に見つかったすべてのバグが、発生元のチャーターと再現手順への参照を付けて記録されている
• 時刻が記録された観察に BUG、QUESTION、IDEA、RISK、NOTE のタグを付けたセッションログが存在する
• 調査結果の概要に、セッション総数、報告したバグ（重大度別）、特定したテストアイデア、予定または明示的に延期したフォローアップセッションが記載されている

参考ファイル（references/ 内）

• session-templates.md — チャーターの例、環境準備チェックリスト、セッションの進行時間、デブリーフテンプレート、メモ用セッションログの形式。
• heuristics-and-automation.md — 境界値／状態／エラー／「もしも」のヒューリスティックに基づくテストアイデア集、探索から自動化へのパイプライン図、Playwright 回帰テストの実例。

関連スキル

• agentic-browser-testing -- 自動化された探索の手段です。ブラウザーエージェントがスクリプトを使わず、自然言語の目標に基づいてアプリを探索します。無人で行う探索的スモークテストにはこちらを、人がチャーターに基づいて実施するSBTMセッションやバグ探しにはexploratory-testingを使用してください。
• playwright-automation -- 探索で得られた安定した知見を、保守可能で決定論的な回帰テストへと発展させます。
• test-planning -- スプリントのテスト計画では、探索セッションの時間を確保し、チャーターを参照します。
• risk-based-testing -- リスク評価によって、どの領域に探索的な注意を払うべきかを特定します。
• test-reliability -- 探索を通じて特定された不安定な領域や信頼性の低い領域は、テストの信頼性向上に役立ちます。
• qa-metrics -- 探索セッション数、バグ発見率、チャーターのカバレッジをQAメトリクスとして追跡します。
• qa-project-context -- プロジェクトコンテキストファイルには、チャーター作成の指針となる既知のリスク領域や過去のバグの集中箇所が記載されています。