test-plan

test-plan: テスト計画 + プロダクトリスク評価

ISTQB/JSTQB のテストプロセス 7 活動のうち テスト計画（test planning） を担う単機能スキル。 テスト対象の プロダクトリスク（product risk） を識別・評価し、それを根拠に テストアプローチ・開始/完了基準を定めた計画書 test-plan.md を 1 本作る。

このスキルは テスト計画だけ を作る。テスト条件の識別（test-analyze）・テストケース設計 （test-design）・実装・実行・レポートは各専用スキルの担当で、ここでは呼び出さない。 単発のテスト作成依頼（単にユニットテストを 1 つ書きたいだけ）は対象外 — その場合は 通常のコーディング支援で対応する。

このスキルが従う横断原則

testing-skills 全 8 スキル共通の原則。test-plan はこの型を確立する参照実装。

1. ファイル規約 + 任意入力

• 成果物の既定パスは docs/test/<テスト対象名>/test-plan.md。
• プロジェクト側（CLAUDE.md / AGENTS.md 等）に成果物の配置規約があればそちらを優先する。 着手前にリポジトリを調べ、既存の docs/ 構成やテストドキュメントの慣習に合わせる。
• 前工程の成果物は test-plan には無い（テストプロセスの起点なので）。ただし PRD・仕様書・ 設計ドキュメントが規約パスにあれば 入力として読む。
• 前工程スキルの成果物を代作しない（test-plan には前工程が無いため該当しないが、 後続スキルはこの原則で「無ければ前工程スキルの実行を提案するに留める」）。

2. 調査優先 + 決定のみ質問

• 事実はリポジトリ調査で埋める。テスト対象のコード・仕様・依存関係・既存テストの有無・ CI 構成などは、利用者に訊く前に自分で調べる。
• 利用者にしか決められない判断だけ を AskUserQuestion で確認する。test-plan では 主に リスク許容度・優先度・完了基準のしきい値 がこれに当たる（推奨案を先頭に添えて訊く）。
• 流れは 調査 → ドラフト提示 → 承認 → 規約パスへ書き込み。承認前に確定ファイルを書かない。

3. 改善提案と仕様反映（early testing 原則）

• 計画立案中に見つけた テスト対象・仕様・テスタビリティの問題（仕様の矛盾・曖昧さ、 テスト困難な構造、観測不能な状態など）は、成果物の「改善提案」セクションで 提示 する。
• 起票前に既決事項を照合する。test-plan に前工程は無いが、プロジェクトのメモリや既存 ドキュメント（PRD・仕様書・作業計画等）に同じ問題が既に記録され、対応先（詳細設計送り・ 作業計画送り等）が確定しているものは改善提案に 再掲しない。必要なら「次のステップ」欄の 参照 1 行に留める。改善提案には この工程で新規に見つけた未解決の問題だけ を載せる。
• 仕様の穴は提示で終わらせない。利用者の決定を AskUserQuestion で確認し、決定が出たら その内容を仕様書へ反映する作業まで行う（反映先の仕様書が規約パスにある場合）。 実装・詳細設計レベルで解決すべき決定は、仕様書ではなく作業計画・メモリ等へ退避する。
• 反映が済んだ提案は「改善提案」セクションから削除する（「反映済み」注記で残さない。 決定の記録は仕様書の改訂履歴が担う）。全提案が解消したらセクションごと削除して番号を詰め、 未解決の提案が残っている間だけセクションを維持する。
• スキル自身がテスト対象のコードを修正しない。early testing は「早期に欠陥を見つけて 指摘する」ことであり、コード修正の実施ではない。

4. 単機能の堅持

• test-plan は テスト計画の成果物だけ を作る。他スキルを呼び出さず、相互参照もしない。
• 後続工程が必要なら、成果物末尾で 次に /test-analyze を実行することを提案 するに留める （代わりに分析・設計を進めない）。

5. Progressive disclosure

• 本文は簡潔に保ち、テンプレ・詳細は references/ に置く。
• テンプレ: references/template.md（test-plan.md の雛形）。
• mini サマリ雛形: references/mini-template.md （mini-test-plan.md の雛形。手順 5 で使う）。

6. 成果物の記述スタイル

• 略号・コードネームを定義なしで使わない（例: 仕様書内の G3 のような社内略号）。 初出で正式名称・意味を併記するか、平易な表現に開く。成果物単体で読み返して意味が 取れることを基準にする。
• スキルの実行記録を成果物に含めない。利用者との Q&A ログ・フェーズ別実行時間などは 対話のテレメトリであって、レビュー対象の内容ではない。利用者との決定事項は本文の該当箇所 （根拠・凡例等）へ埋め込み、実行記録が必要なら scratchpad 等へ分離する。

手順

手順 0: テスト対象の確定

• 引数 <テスト対象名> があればそれを対象名とする。無ければ利用者に一言で確認する （例: 「決済 API」「ユーザー登録フロー」）。対象名は成果物パス docs/test/<テスト対象名>/ のディレクトリ名にも使う（英数字・ハイフンへ正規化）。

手順 1: 調査（事実収集）

原則 2 に従い、以下を 自分で調べる（利用者に訊かない）:

• テスト対象の範囲: 対象コード・モジュール・機能の境界。関係するファイル・エントリポイント。
• 既存の仕様・設計: docs/・README・PRD・設計書・型定義・API スキーマ。
• 既存テストと CI: 現状のテストの有無・種別・カバレッジ・CI 構成（後続 test-monitor の下地）。
• 配置規約: CLAUDE.md / AGENTS.md の成果物配置ルール（原則 1）。

手順 2: プロダクトリスクの識別・評価

test-plan の核。プロダクトリスク（product risk）= 対象が期待どおり動かないことによる、 プロダクト側の悪影響 を洗い出し、2 軸で評価する。

• 発生可能性（likelihood）: 複雑さ・変更頻度・新規性・過去の欠陥密度・依存の多さ等から見積もる。
• 影響度（impact）: 障害時のビジネス影響・安全性・データ破損・ユーザー数・回復コスト等から見積もる。
• 各軸を 3 段階（高/中/低）等で評価し、リスクレベル = 発生可能性 × 影響度 で優先度を付ける。
• 見積もりの根拠（なぜその可能性/影響度か）を必ず添える。事実は手順 1 の調査から引く。
• リスクの実在性をコードで検証する: 計上前に該当経路のコードを読み、発生し得ることを 確認する。防御的プログラミングとして書かれた実際には到達しない分岐を実リスクとして 計上しない（その場合は「データ 0 行でも所定の出力がされること」のような、実際に起き得る 観点へ言い換える）。

リスク許容度・優先度の判断が利用者依存なら、ここで AskUserQuestion（推奨案先頭）で確認する。

手順 3: テストアプローチと開始/完了基準の決定

リスク評価を 根拠 にして計画の骨子を決める:

• テストアプローチ: 高リスク領域を厚く（テストレベル・テストタイプ・技法の重点配分）、 低リスク領域は軽く。「どこを・なぜ厚く/薄くするか」をリスクと紐づけて書く。
• 開始基準（entry criteria）: テスト開始の前提（環境・仕様確定・ビルド成功等）。
• 完了基準（exit criteria）: どうなったらテスト完了とみなすか（カバレッジ・残欠陥・ 高リスク項目の消化率等）。後続の test-monitor / test-report がこの基準を参照するため、 測定可能な形で書く。しきい値の許容度は利用者判断なので必要なら確認する。
• スコープ外・前提・リソース/スケジュール制約・成果物一覧も簡潔に添える。
• スコープ判定: テスト対象の実行に必須の依存（インフラ定義・設定・前段処理等）は、 別リポジトリ・別チーム管轄でもスコープ内に含める。逆に、既に実装済みで今回の変更で 触れない要素はスコープ表に載せない（誤解を招きやすいものだけ、理由付きでスコープ外に明記）。

手順 4: ドラフト提示 → 承認 → 書き込み

• references/template.md の構成で test-plan.md のドラフトを作り、 本文で提示して承認を得る（原則 2）。
• 承認後、規約パス（既定 docs/test/<テスト対象名>/test-plan.md、プロジェクト規約があれば優先）へ書き込む。
• 手順 1〜3 で見つけた対象・仕様・テスタビリティの問題は「改善提案」セクションに記載（原則 3）。
• 末尾で 次工程 /test-analyze <テスト対象名> の実行を提案 する（原則 4）。自分では進めない。

手順 5: mini サマリの作成（レビュー収束後）

• 本編 test-plan.md への利用者フィードバックが出なくなり、確認が完了したら、同ディレクトリに 初見者向けサマリ mini-test-plan.md を作成する。レビュー中は作らない （フィードバックのたびに本編と同期し直すことになるため、収束後に一度だけ作る）。
• 構成は references/mini-template.md に従う。対象ドメインに 詳しくない人へ短時間で説明できる状態を目指し、見出しは「何が怖いか」「いつ終わりか」の ような問いの形にする。

手順 6: 終了条件の確認と完了宣言

テスト計画の終了条件（exit criteria）は以下。利用者に「終わりか」と訊かれる前に、 スキル側で判定して宣言する:

1. プロダクトリスクが実在性検証つきで評価済み（手順 2）。
2. テストアプローチ・開始/完了基準が承認済みで、完了基準が測定可能な形で書かれている（手順 3）。
3. 承認済みの test-plan.md が規約パスへ書き込み済み（手順 4）。
4. 改善提案が空（各提案が仕様反映・対応先確定のいずれかで解消済み）。
5. test-review ゲート: /test-review <テスト対象名> plan の判定が「通過」または 「条件付き通過」（記録 test-review-plan.md）になっている、もしくは利用者がゲートの スキップを明示している。未実施なら完了宣言せず、利用者へ実行を促す （test-review は明示起動のみで、本スキルからは起動できない）。
6. mini サマリ作成済み（手順 5）。

• 全て満たしたら 「テスト計画は完了」と明言 し、/test-analyze <テスト対象名> の提案で 閉じる（原則 4）。
• 満たしていない項目があれば、何が残っているかを列挙して先へ進めない。

用語（JSTQB 訳語 / 初出英語併記）

• プロダクトリスク（product risk）: テスト対象が期待どおり動かないことによる悪影響。
• 発生可能性（likelihood）× 影響度（impact）: リスク評価の 2 軸。
• テストアプローチ（test approach）: リスクに応じたテストの重点配分方針。
• 開始基準（entry criteria）/ 完了基準（exit criteria）: テストの開始/完了の判定条件。