test-planning

スプリントやリリースのための、実行可能なテスト計画を作成します。テスト計画では、何をテストするか、どの程度深くテストするか、誰が担当するか、いつまでに完了する必要があるかという4つの問いに答えます。出力は進捗を追跡するための生きたドキュメントであり、保管されて忘れられるだけの事務的な書類ではありません。利用可能な時間の100％を予定で埋めた計画は、最初のバグが見つかった時点で破綻します。バッファと優先順位付けがあってこそ、現実に直面しても計画を維持できます。

クイックルート

状況	移動先
1つのスプリントを計画する	以下のステップ1～6に進み、その後 references/plan-documents.md の1ページのスプリントテンプレートを使用します
リリースを計画する	references/plan-documents.md のリリーステンプレートを使用します。Go／No-Go の判断自体は release-readiness の担当範囲です
進行中の計画を追跡する／結果をフィードバックする	references/tracking-formats.md（日次ステータス＋振り返り）
容量を超過したときに何を削るか決める	ステップ4の優先順位付けマトリクス

---

調査の質問

テスト計画を作成する前に、状況を把握します。まず .agents/qa-project-context.md を確認してください。ファイルが存在する場合は、それを基礎情報として使用し、すでに回答されている質問は省略します。

スコープ

• スコープは何ですか？（単一のスプリント、リリース、ホットフィックス、機能）
• どの機能が新規、変更あり、変更なしですか？
• 初めてリリースされる機能はどれですか？
• インフラストラクチャや依存関係に変更はありますか？（データベースのマイグレーション、API のバージョン引き上げ、サードパーティプロバイダーの切り替えなど）
• 対応付けの対象となる要件ドキュメント、PRD、ユーザーストーリーはありますか？

時間とリソース

• テスト期間はどのくらいですか？（利用可能な日数、時間）
• テストに参加できるのは誰ですか？（SDET、手動テスター、開発者）
• ボトルネックになる可能性のある共有リソースはありますか？（ステージング環境、テストアカウント、デバイス）
• 変更できない厳格な期限はありますか？それともリリース日は調整可能ですか？

リスクの状況

• 今回のサイクルで最も変更が多かった領域はどこですか？
• 前回のリリースまたはスプリントでは何が壊れましたか？
• リスクを高める、脆弱性が知られている領域や技術的負債はありますか？
• リスクベースの優先順位付け手法については、risk-based-testing を参照してください。

既存のテストカバレッジ

• 対象機能について、既存の自動テストにはどのようなものがありますか？
• 自動テストスイートの現在の合格率はどのくらいですか？
• 手動テストが必要となる、自動化の既知の不足箇所はありますか？
• これらの機能に対する直近の探索的テストはいつ実施されましたか？

---

基本原則

1. カバレッジ主導：すべての要件を少なくとも1つのテストに対応付ける

要件への追跡可能性がないテスト計画は、推測にすぎません。すべてのユーザーストーリー、受け入れ基準、要件を、少なくとも1つのテストケースに対応付ける必要があります。この対応付けに抜けがあると、未テストの要件が生まれます。これは最も危険な種類のリスクです。

2. タイムボックス制：計画を利用可能な期間に収める

制限を設けなければ、テストは利用可能な時間をすべて使い切るまで膨らみます。各作業にタイムボックスを設定し、それを守ってください。期間が短すぎる場合は、何を削るかを直感ではなく優先順位付けマトリクスで決めます。

3. 優先順位付け：すべてを同じ深さでテストするわけではない

決済フローの変更とツールチップの修正に、同じ工数をかける必要はありません。リスク×工数マトリクスを使ってテストの深さを割り当てます。機能によっては完全なリグレッションテストを行い、別の機能はスモークテストにとどめます。また、リスクが低く変更もない場合は、テストを行わないこともあります。

4. バッファを確保する：予期しない事態に備える

利用可能な時間の100％を予定で埋めた計画は、バグが見つかった時点で破綻します。テスト期間の70～80％だけを計画済み作業に割り当て、残りの20～30％は、バグの検証、再テスト、予定外の調査に明示的に確保してください。計画にバッファが明記されていなければ、バッファを確保したことにはなりません。

5. 可視化する：計画はコミュニケーションツール

開発者はテスト対象を把握することで、テストしやすいコードを書けます。プロダクトマネージャーはカバレッジを把握することで、リリースを判断できます。チームが確認できる場所に計画を公開してください。

6. 開始条件と終了条件を最優先で明確にする

どの計画でも最も頻繁に参照されるのはゲートです。埋もれさせず、明確にしましょう。開始条件＝ステージング環境でコードが完成していること＋既存のテストスイートがすべて成功していること＋テストデータが投入済みであること、終了条件＝HIGH リスク領域がすべてカバーされていること＋未解決の P0/P1 がないこと＋カバレッジマトリックスに説明のない GAP 行がゼロであること。それ以外は、この2つのチェックポイントに関する詳細です。

---

ワークフロー

ワークフローの6つのステップには、それぞれ空欄を埋める形式のひな形があります。判断に関する説明はここに記載し、コピー＆ペースト用のテンプレート（分解、カバレッジマトリックス、見積もりワークシート、優先順位付けマトリックス、割り当て表、スケジュール）は references/workflow-templates.md にあります。

ステップ 1：機能の分析と分解

対象範囲内の各機能を、テスト可能な単位に分解します。「テスト可能な単位」とは、明確な合否で検証できる具体的な動作です。見落としがないよう、次のシナリオカテゴリに照らして各機能を確認します。

• 正常系 — 主な成功フロー。
• バリデーション — 必須フィールドが空、形式違反、境界値。
• エラー条件 — サーバーの 5xx、ネットワークタイムアウト、入力の拒否。
• エッジケース — Unicode、過大なペイロード、未対応の形式。
• 同時実行／競合状態 — 2人のユーザーが同じレコードを同時に編集する、二重送信、タイムアウト後の再試行。こうしたケースは、最も深刻なデータ破損バグを引き起こす可能性があり、最も見落とされやすいカテゴリです。
• 統合ポイント — 機能がまたがる各境界での動作。

分解テンプレートと、6つのカテゴリすべてを網羅した「ユーザープロフィール編集」の記入例については、references/workflow-templates.md を参照してください。

AI による分解のクロスチェック。 エージェントが機能を分解する際は、そのシナリオを直ちにステップ 2 のカバレッジマトリックスに照らして対応付けるようにします。シナリオがない要件や、上記のシナリオカテゴリのうち項目がないものがあれば、それは分解漏れです。見積もりの前にエージェントが明らかにしなければなりません。これにより、CI が検出してからではなく、エージェントの見落としを発見できます。

ステップ 2：要件とテストのカバレッジマッピング

すべての要件をテストケースに対応付けるトレーサビリティマトリックスを作成します。カバレッジマトリックスのテンプレートについては、references/workflow-templates.md を参照してください。

カバレッジマトリックスのルール：

• すべての要件をマトリックスに含めます（目標：マッピング率 100%）。
• ステータスが「GAP」の場合は、テストを作成する、リスクを受け入れる、または延期する、という判断が必要です。
• 自動テストには、実際のテストファイル／関数にリンクするテスト ID を付けます。
• 手動テストでは、テストケースのドキュメントまたはチャーターを参照します。

ステップ 3：工数の見積もり

過去のデータを使って、各テストタイプの工数を見積もります。過去のデータがない場合は、以下の参考見積もりを使い、最初のスプリント後に調整してください。

見積もりの参考値（テストケースあたり）：

テストタイプ	作成時間	実行時間	メンテナンス（四半期あたり）
単体テスト	0.5 時間	< 1 秒	5 分
統合テスト	1 時間	5-30 秒	15 分
E2E テスト（Playwright/Cypress）	2-3 時間	30 秒-2 分	30 分
手動テストケース（作成）	0.25 時間	1 回の実行につき 5-15 分	10 分
探索的テストセッション（チャーター）	15 分	1 セッションにつき 1.5 時間	N/A
アクセシビリティレビュー（手動）	領域あたり 0.5-1 時間	作成時間に含む	15 分
ビジュアルリグレッションテスト	30-60 分	10-30 秒	20 分（ベースラインの更新）
パフォーマンステスト（k6 スクリプト）	2-4 時間	1 回の実行につき 5-30 分	30 分
プロンプトのリグレッション／LLM 評価	ケースあたり 30-60 分	30 秒 - 2 分（API コストあり）	20 分
セットアップとテストデータ（機能あたり）	0.5-2 時間	1 回限り	環境ごとに再投入

作成時間はテストの作成のみを指します。「セットアップとテストデータ」の行は、計画担当者が最も省略しがちな項目です。環境、フィクスチャ、モックの設定には、総工数の 20-40% が日常的にかかるため、スプリントの途中で気づくのではなく、実際の項目として工数に含めてください。

AI による作成のトレードオフ。 エージェントを使ってテストを作成すると、作成時間 はおよそ 40-60% 短縮できますが、ケースごとに同程度の レビュー時間 も計上してください。Bolton の「AI 生産性のパラドックス」（2026）とは、エージェントが一見もっともらしいものの壊れたテストを作成し、表面的なレビューには合格して CI で失敗すると、速度向上が帳消しになるというものです。レビューのチェックリストについては ai-test-generation のステップ 7 を、アンチパターンの分類については ai-qa-review を参照してください。

テストスメルのレビュー。 ISTQB の CTAL-AT v2.0（2026 年 5 月）では、テストスメルを計画上の懸念事項として挙げています。ai-qa-review の分類に沿って、スプリントごとに定期的な 30 分の「テストスメルレビュー」を計上してください。低コストで、メンテナンス負債が膨らむ前に発見できます。

references/workflow-templates.md のスプリント見積もりワークシートを使って、ケースごとの見積もりを集計し、稼働率を算出してください（目標：70-80%、20-30% のバッファを確保）。

ステップ 4：優先順位マトリックス（リスク × 工数）

見積もり工数が利用可能なキャパシティを超える場合（通常は超えます）、リスク × 工数マトリックスを使って、削減する項目を決めてください。マトリックスの全体図は references/workflow-templates.md を参照してください。

各テストケースについて、risk-based-testing のリスクスコアとステップ 3 の工数見積もりを使ってマトリックス上に配置し、優先順位に沿ってキャパシティを割り当ててください：最初に実施 → 2 番目に実施 → 3 番目に実施 → 延期 → 省略。

同順位の場合のルール： HIGH リスク内では、工数が少ないものを工数が多いものより優先します。リスク低減を 1 時間あたりで最も多く得られるため、HIGH リスク／低工数のテスト（最初に実施）は、HIGH リスク／高工数のテスト（3 番目に実施）より優先されます。HIGH リスクのテスト範囲を削る前に、中リスクの項目を延期してください。低リスクの項目は延期するか、完全に省略してください。計画済みの作業を増やすために、バッファを削ることは決してしないでください。

ステップ 5：リソースの割り当て

スキルの適合性と稼働状況に基づいて、テスト作業を割り当てます。

割り当ての原則：

• 自動テストの作成は、SDET またはフレームワークの経験がある開発者に割り当てます
• 探索的テストは、その機能を最もよく理解している人（多くの場合、QA だけでなく開発者やプロダクトマネージャー）に割り当てます
• 新機能のテストでは、第三者の視点が役立つため、開発に携わっていない人に割り当てます
• クリティカルパスのテストは、単一障害点を避ける必要があります。2 人が対応できるようにしてください
• 各担当者の稼働率は 100% ではなく 70-80% にします。残りはバッファです
• バッファは 1 人のテスターの枠にまとめず、担当者ごとに配分します。各担当者に個別のバッファ項目を設けることで、1 人の作業を妨げる要因が他の全員の余力を消費しないようにします

割り当て表の形式については、references/workflow-templates.md を参照してください。

ステップ 6：バッファを設けてスケジュールを立てる

テスト活動をスプリントのタイムラインに割り当てます。テストを最後の 2 日間に集中させないでください。2 週間のスプリントスケジュールのテンプレートについては、references/workflow-templates.md を参照してください。

スケジュール作成の主なルール：

• テストはスプリントの終了時ではなく、機能のコードが完成したらすぐに開始します
• 環境のセットアップとテストデータの準備は 3 日目ではなく 1 日目に行います
• バグの検証はまとめて行うのではなく、継続的に行います
• 最終日は確認に充て、新しいテストを開始する日にはしません

---

計画ドキュメント

コピーしてそのまま使える計画ドキュメント一式は references/plan-documents.md にあります。

• スプリントテスト計画（1 ページ） — スコープ、カバレッジの概要、工数の予算、開始／終了基準、計画上のリスクをまとめます。スプリント計画は 1 ページに収めてください。
• リリーステスト計画 — スプリント計画を集約し、リリース固有の考慮事項（完全なリグレッション、クロスブラウザー、パフォーマンスベンチマーク、セキュリティスキャン、スモークテスト）と go/no-go 基準を追加します。go/no-go の 判断 自体は release-readiness に属します。
• 機能カバレッジマトリクス — 機能ごとのシナリオ一覧に、優先度、テスト種別、場所、ステータスを記載します。
• テスト見積もりワークシート — 新規テストの開発、既存テストスイートの実行、手動テスト、および利用可能なキャパシティとの差分の概要をまとめます。

---

スプリント中の進捗管理

1 日目以降に誰も確認しないのであれば、テスト計画は役に立ちません。毎日進捗を追跡し、スプリント終了時にその結果を今後の計画に反映してください。

• 日次テスト状況 — 完了事項、ブロック中の項目、発見したバグ、翌日の計画、カバレッジ率、消費したバッファを記録します。形式については references/tracking-formats.md を参照してください。
• スプリントの振り返りに用いる情報 — テスト種別ごとの見積もり精度、カバレッジの差分、重要度別のバグ件数、教訓をまとめます。形式については references/tracking-formats.md を参照し、これらのデータを次のスプリントの見積もりに反映してください。

---

アンチパターン

リスク評価をせずに計画する

すべての機能を同じ深さで扱うと、低リスク領域に労力を浪費し、重要な経路のテストが不足します。労力を割り当てる前に、必ず優先順位付けマトリクス（ステップ 4）を実施してください。リスク評価の詳しい手法については、risk-based-testing を参照してください。

バグ発見に備えたバッファがない

利用可能な時間をすべて計画済みの活動に割り当てると、バグ発見後の検証時間がなくなります。20～30% をバッファとして確保し、消費状況を毎日追跡してください。

テストをスプリントの終了時に集中させる

最後の 2 日間にすべてのテストを残しておくと、カバレッジが不十分になり、修正が間に合わない時期にバグが見つかります。機能が利用可能になり次第テストを開始してください。スプリント終了時にまとめてテストするより、継続的にテストする方が効果的です。

テスト計画をコンプライアンス用の書類にする

作成後に忘れ去られる 30 ページの計画書は、誰の役にも立ちません。計画はスプリントごとに 1 ページにまとめ、積極的に進捗を追跡し、毎日更新してください。計画が変わらないのであれば、誰も使っていません。

履歴データなしで見積もる

根拠のない工数見積もりは信頼できません。テスト種別ごとに実際の所要時間を記録し、今後の見積もりにそのデータを使ってください。2～3 回のスプリントを経れば、見積もりの信頼性が高まります。

環境とデータのセットアップを無視する

環境のセットアップ、テストデータの作成、モックの設定には、テスト工数の 20～40% がかかることがあります。ステップ 3 の「セットアップとテストデータ」の行を見積もりに含めてください。含めないと、計画どおりに終わらない状態が続きます。

重要な経路を 1 人だけでカバーする

重要な経路の作業を 1 人のテスターだけで担当すると、障害点になります。重要な経路のテストをカバーできる人を、少なくとも 2 人確保してください。

---

検証

作成した計画を開き、次の点を確認してください。スプリントボードの対象範囲内にあるすべてのチケット ID がスコープ表に記載されていること、カバレッジマトリクスに説明のない GAP の行がないこと（各 GAP に受け入れまたは延期の注記があること）、割り当てたキャパシティの合計が 70～80% で、明示的なバッファの行があること、開始／終了基準のチェックリストがプレースホルダーではなく記入済みであることです。これらのいずれかを満たしていなければ、計画は未完成です。

完了条件

• スプリントまたはリリースのテスト計画書（1ページのスプリントテンプレートまたはリリーステンプレート）があり、スコープ表、カバレッジの概要、工数予算、開始・終了基準がすべて記入されていること — プレースホルダーがないこと
• 対象範囲内のすべての機能が、合格／不合格の基準を備えた具体的なテスト可能シナリオに分解され、正常系、バリデーション、エラー、エッジケース、並行処理の各カテゴリを網羅していること
• 要件とテストのカバレッジマトリックスがあり、説明のない GAP がないこと（すべての GAP にリスク受容または延期の注記があること）
• 各シナリオが見積もられ、リスク × 工数マトリックスにプロットされていること。延期項目が明示的に一覧化されていること
• 割り当て済みのキャパシティが70～80％で、20～30％のバッファが名前付きの項目として明示的に確保されていること
• テストデータの要件、環境の詳細、リソースの割り当てが計画書に記載されていること

参考ファイル（references/ 内）

• workflow-templates.md — 6つのワークフローステップ用の記入式テンプレート一式：分解テンプレートと例、カバレッジマトリックス、スプリント見積もりワークシート、リスク×工数マトリックスグリッド、割り当て表、2週間のスケジュール。
• plan-documents.md — そのままコピーして使える文書一式：1ページのスプリントテスト計画書、リリーステスト計画書、機能カバレッジマトリックス、見積もりワークシート。
• tracking-formats.md — 日次テスト状況のフォーマットと、スプリント振り返りの入力フォーマット（テスト種別ごとの予実差を含む）。

関連スキル

• test-strategy -- テスト計画の実行基盤となる、より広範なQA戦略です。戦略でアプローチを定め、計画ではそれを各スプリントに適用します。
• risk-based-testing -- ステップ4の優先順位付けマトリックスに反映する、リスク評価の詳細な手法です。
• release-readiness -- リリーステスト計画の終了基準が判断材料となる、リリース可否の決定です。このスキルでは計画を作成し、もう一方ではリリース可否を判断します。
• qa-metrics -- 不具合流出率や見積もり精度など、今後のテスト計画を改善するための指標です。
• exploratory-testing -- 計画書の手動テストのセクションで参照する、構造化された探索的テストセッションです。
• qa-project-context -- ディスカバリーの質問に対する基本情報を提供する、プロジェクトコンテキストファイルです。