exploratory-testing

探索的テスト（exploratory-testing）

要件が不完全、システムに不慣れ、ドキュメントが不足している場合に行う独立した探索的テストセッションです。チャーターを軸に、探索しながらテストを設計し、既存のテストケースを実行するのではなく、システム理解とリスク一覧を作成します。

• 入力：テスト対象システムへのアクセス情報（環境＋アカウント）、探索テーマまたはチャーター、（任意）既存の要件資料
• 出力（ファイルに保存）：{プロジェクト}/探索ノート_{テーマ}.md（チャーター、システム理解、リスク一覧、テストアイデア、発見した Bug）——並行シナリオでは requirement-analysis の入力として使用
• 適用対象：新規システム、既存システム、ドキュメント不足、ブラックボックステスト、エージェントによる自律テスト

使用する場合

• 新たに担当する／不慣れなシステムで、ドキュメントが不足している、または信頼できない場合。まず探索してからモデル化します
• 要件が不完全で、探索によってシステム理解とリスク一覧を補う必要がある場合
• アクセス情報とアカウントのみがあるブラックボックス環境で自律テストを行う場合

使用しない場合

• 自動化のための下見（ページ構造の把握、セレクターの抽出、Page Object への記述）→ automated-e2e-testing ワークフローゼロ（業務理解）
• 既存のテストケースに沿って実行する場合 → automated-e2e-testing（UI）／api-testing（インターフェース）
• 確認済み Bug の根本原因分析 → bug-analysis
• エンドツーエンドのパイプライン → qa（この skill はその並行フェーズ 0 です）

探索ノートのスキーマ（出力構造）

# 探索笔记：{主题}

## Charter（本轮探索的使命）
- 目标：{回答什么问题 / 覆盖什么区域}
- 范围：{系统/模块/流程}
- 时长/停点：{时间盒或停止条件}

## 系统理解（探索中修正）
- 入口与导航路径 / 角色与权限 / 核心流程 / 数据流向 / 状态与流转

## 风险清单（每条带证据标注，此时加载 `../core/evidence.md`）
- R?：{风险描述}｜level: {Critical/High/Medium/Low，按 `../core/risk-model.md` 的 Impact × Likelihood 预评}｜evidence: {E0–E4 + 来源}｜confidence: {high/medium/low}｜status: {fact / inference / risk / hypothesis}
  （R? 为会话内临时编号；移交 `test-strategy` 时并入其 Risk Map 统一重编为 R1…，探索笔记原文编号不保留）

## 测试想法（后续转化为正式用例的候选）
- 想法 → 建议归属：{test-case-writing 直接产出 / 需先澄清的问题}

## 发现的 Bug（现象 + 复现步骤 + 证据；未定性，标 Hypothesis）

## 未解之谜（需要用户/开发澄清的问题）

ワークフロー

1. チャーターの策定（使命を定めてから、着手する）

• チャーターの 3 要素：目標（「クーポン取得の前提条件は何か」など、どんな問いに答えるか）、範囲（対象のシステム／プロセス）、終了条件（タイムボックス、または「リスク一覧が 10 件に達したら」など）
• テーマが不明な場合、ユーザーと「今回の探索で何を明らかにしたいですか？」と認識を合わせます
• 環境／アカウントがない場合は、まず情報を依頼します（アクセス先、各ロールのアカウント、データの説明）。認証情報なしでは探索を開始しません

2. システムの初期調査（初期マップの作成）

• ログイン → アクセス先とナビゲーション経路を列挙 → 各ロールから見える機能領域を記録
• 発見可能な主要フローを一通り実行し、ページ／インターフェース、データオブジェクト、状態と遷移を記録
• ホストで利用可能なブラウザー自動化機能（ナビゲーション、スクリーンショット、API 監視／パケットキャプチャ）を使って証拠を収集し、この skill のノート構造に沿って成果物を作成します——セッションと成果物はこの skill に属します。このために他の実行 skill の指示を読み込むことはありません。ホスト／環境にブラウザー自動化機能がない場合は手動探索に切り替えます（テストエンジニアが手順に沿って操作し、手動でスクリーンショットを撮影／応答を転記）。ノート構造と証拠のラベル付けは変わらず、証拠収集の効率のみが低下します

3. 探索サイクル（設計・実行・記録を並行して行う）

チャーターの目標に沿って、次のサイクルを繰り返します：仮説 → 発動 → 観察 → 記録：

探索ヒューリスティック	問い
入力の極値	空値／極端に大きな値／特殊文字／負数を、システムはどう処理するか
状態の遷移	手順を飛ばす操作（前提条件を満たさずに後続処理を直接実行）、逆方向の操作、繰り返し操作
並行処理と競合状態	2 つのセッションで同じオブジェクトを同時に操作する
データのライフサイクル	作成→変更→削除→再検索で、データは残るか。カスケード対象はどうなるか
権限境界	ロールを切り替える／ログアウトした後に、同じ操作を再実行する（インターフェースへの直接呼び出しを含む）
エラーからの復旧	失敗後の再試行、ネットワーク切断後の再接続、タイムアウト後の状態
プラットフォームと環境	ブラウザー／解像度／低速ネットワーク／システム設定の切り替え後も、挙動は一貫しているか
時刻とクロック	0 時／日付をまたぐ境界、期限切れやスケジュールタスクの実行タイミングにおいて、状態と文言は正しいか

• 各観察には証拠レベルを記録します（E3 の実行証拠を優先——スクリーンショット／応答の原文）。推測は Inference/Hypothesis として記録し、事実のように扱いません
• 異常を発見したら、記録前に分類します：「これは想定どおりの挙動ですか、それとも Bug ですか？」判断できない場合は未解決事項として記録し、ユーザーに確認します。独断で判定しません（質問形式と判定結果の記録は ../core/clarify-pattern.md に統一し、シナリオには「Bug の判定」を使用します）

4. 収束とファイルへの保存

• タイムボックスに達した／終了条件を満たしたら、探索ノートを整理して 探索ノート_{テーマ}.md に保存します
• ナレッジ蓄積の判定：探索で確認した業務ルール、環境固有の挙動、flaky ノイズの判定基準が qa-memory の書き込み基準を満たす場合（新しいセッションで再テストする際に再発見の手間を省ける場合）、その手順に従ってプロジェクトの .qa/ ナレッジベースに蓄積します
• リスク一覧は ../core/risk-model.md に従って事前評価します（Impact × Likelihood。不十分な証拠しかない場合は、status に risk/inference を記載し、補強方法を明記します。status の列挙値以外のラベルは使用しません）
• テストアイデアを次のように分類します：そのままテストケースに変換できるもの／事前確認が必要なもの／専用環境が必要なもの

5. 成果物の提出と引き継ぎ

• 並行シナリオ（qa パイプライン／要件のモデル化前）：ノートのパスを requirement-analysis に渡し、モデル化の入力として使用します
• 独立したシナリオ：ノートに加え、システムの理解度／最大のリスク／推奨する次のステップを一文でまとめ、ユーザーに提出します
• Bug の引き継ぎ：確認済み → bug-analysis。テストアイデアを正式なテストケースに変換 → test-case-writing

よくある間違い

間違い	結果	正しい方法
チャーターなしであてもなく探索する	探索が散漫になり、成果物が断片的になります	先に目標／範囲／終了条件を定めます
探索を下見として扱う（セレクターだけを収集する）	e2e ワークフローゼロとの役割が混同されます	成果物はシステム理解＋リスク一覧であり、Page Object ではありません
観察結果の証拠を記録しない	ノートを検証できず、リスク一覧が役に立たなくなります	各観察に証拠レベルと出典を記録します
異常を独断で Bug と判定する	誤報になります（想定された設計の場合もあります）	判定できない場合は Hypothesis として記録し、ユーザーに確認します
探索で見つけたことをすべてその場で正式なテストケースにする	セッションの焦点がぶれ、タイムボックスを守れなくなります	テストアイデアとして記録し、セッション後にまとめて変換します
ノートをセッション内に残し、ファイルに保存しない	後続工程で利用できず、再開地点も失われます	探索ノート_{テーマ}.md に保存します