authoring-test-plan

authoring-test-plan — SKILL.md

バリアント： 標準 · 使用するタイミング： プロジェクトの QA／検証計画を作成（または修正）するとき。テスターが追加の質問なしで実行でき、すべての振る舞いに追跡可能なケースが少なくとも 1 つあり、カタログが組み合わせ網羅ではなくリスクに基づいており、妥当な非機能テストに数値目標が設定されている水準を目指します。

概要

このスキルは、優れたテスト計画（QA／検証計画）を作成するための方法です。つまり、何を、どのレベルで、どの環境で、どのデータを使って、どの完了基準に照らしてテストするか、そして実行する具体的なケースは何かを示す文書です。戦略（スコープ、機能テストのレベルと種類、カバレッジの方針、非機能テスト、環境とテストデータ、開始／終了基準、リスクベースの優先順位付け）と、列挙したテストケースカタログ（各ケースの ID、前提条件、手順、期待結果、トレーサビリティ）の両方を扱います。また、承認済みの計画をバージョン管理された差分として修正する方法も扱います。このスキルが担うのは作成者の判断、つまり調査方法と品質基準であり、セクション一覧ではありません。セクションの構成を提供するテスト計画テンプレートツールと、確立されたテスト戦略の実践に基づいて計画を作成するためのディープリサーチ機能という、2 つの協力要素を前提としています。作成者には、上流の文書（通常、ケースで検証する振る舞いを定めた feature-spec、テスト対象の操作とエラーを定めた api-spec、終了基準を結び付ける PRD の受け入れ条件、そして非機能テストの目標を定めた NFR／architecture-doc）が提供されます。白紙から始めることはありません。基準となる水準は、テスターが追加の質問なしで計画を実行できることです。サポート対象のすべての振る舞いに追跡可能なケースがあり、テストレベル、環境、データが明記され、終了基準がテスト可能で、妥当な非機能テストに数値目標が設定され、カタログの規模がリスクに基づいており、過剰でも不足でもないことが求められます。

使用するタイミング

• システムが満たすべき振る舞いを定めた承認済みの feature-spec（および api-spec／PRD／NFR）から、テスト計画／QA 検証計画を作成するとき。
• 機能テストのレベルと種類、カバレッジの方針、非機能テスト、環境とテストデータ、開始／終了基準、リスクの優先順位付け、テストケースカタログを定めるとき。
• 変更リクエストに基づいて承認済みの計画を修正するとき（上流の振る舞いが変更／追加／削除された場合、または欠陥が見つかった場合）。全面的な書き直しではなく、バージョン管理された差分として修正します（ステップ 8 を参照）。
• 調査に基づく、追跡可能でリスクを考慮した振る舞いごとのカバレッジと、実行可能なケースをテスト計画テンプレートに記入するとき。

次の場合は有効化しないでください：

• テスト自動化コード（実行可能な pytest／Playwright などのスクリプト）を作成するとき。これは実装であり、この計画の下流にあたります。計画ではテスト対象とケースを定めますが、スクリプトは作成しません。
• リリースランブックのデプロイ後検証（運用上のスモークテスト手順）を作成するとき。これは、この計画の終了基準を再利用する別文書であり、QA 戦略ではありません。
• 振る舞いの契約そのもの（feature-spec／api-spec）を作成するとき。これらは上流の入力であり、計画はそれらからカバレッジを導きますが、内容を再定義するものではありません。
• 完成したテスト計画をレビューまたは評価するときは、reviewing-test-plan（対となるゲート）を使用してください。このスキルは作成側専用です。

入力

計画で指定されているすべてのドキュメント（上流のディスカバリーで、この計画に情報を提供すると特定された depends_on セット）を読み、それらに基づいて内容を導き出してください。入力を狭く限定してハードコードしないでください。一般的な上流ドキュメント（feature-spec＋api-spec＋PRD、該当する場合は architecture-doc／NFRs）は手法の参考であり、上限ではありません。実際の入力は、計画で指定されたすべてのドキュメントです。自己完結型にしてください。想定される情報提供ドキュメントがない場合（例：パフォーマンスへのアプローチに関する NFRs ドキュメントがない場合）も、手元にある情報に基づいて進め、不足分を明示的な前提として提示してください。動作や目標を捏造してはいけません。利用可能な場合は、リサーチ機能（deep-research）を使い、確立されたテスト戦略の実践に基づいて計画を作成し、アーキタイプに見合うリスク重視のカバレッジでカタログの規模を決めてください。改訂の場合、入力には既存の計画＋変更リクエストも含まれます。

ワークフロー

ステップ 1：テンプレートツールから構成を取得する — 構成を独自に考案しない

テスト計画のテンプレートツール（包括版）からセクション構成を取得してください。ここでセクション一覧を繰り返したり、再構成したりしないでください。このスキルが提供するのは、そのセクションを埋めるための手法です。包括版テンプレートには、スコープ、機能レベルとテスト種別、カバレッジマトリクス、環境、開始・終了基準、リスクの優先順位付け、テストケースカタログ、不具合／トリアージ、バージョン管理と変更履歴、非機能テストマトリクス、テストデータ管理、リグレッション／変更影響が含まれます。テンプレートを利用できない場合は、依頼するか作成するか、またはこの標準的な構成にフォールバックしてから進めてください。

ステップ 2：上流ドキュメントを読み込み、まずカバレッジマップを作成する — 導き出し、捏造しない

feature-spec（動作＋受け入れ基準）、api-spec（操作＋エラーモデル）、PRD（終了基準がひも付く成功指標）を読み込んでください。これらは入力であり、白紙ではありません。テストケースを作る前に、カバレッジマップを作成してください。feature-spec の動作／受け入れ基準、および api-spec の操作＋エラーケースをすべて行にし、それぞれを、それを検証するテストレベルに対応付けます。このマップをカバレッジのチェックリストとして使ってください。すべてのテストケースはマップ内のいずれかの行にひも付けてください（対応する行のないケースや捏造したケースを作らず、ケースのない動作を残さないこと）。ここが最も重要な要点です。カバレッジと終了基準は、要件＋リスクのカバレッジに基づいて記述してください（すべての動作をテストし、高リスク領域を十分な深さでカバーすること）。単なるコードカバレッジ率にしてはいけません。コードカバレッジ率は下流で測定されるスクリプト上の指標であり、各動作がテストされているかどうかは示しません。上流ドキュメントが不十分、または存在しない場合は、その不足を明示的な前提として示し、暗黙のうちに動作を作り出してはいけません。

ステップ 3：リサーチに基づいて戦略を策定する

deep-research を使い、確立されたテスト戦略の実践に基づいて計画を策定してください。対象には、テストレベル（ISTQB に基づく単体／コンポーネント、統合、システム／エンドツーエンド、受け入れ）、テスト計画の構成（ISO/IEC/IEEE 29119。現行規格です。IEEE 829 は後継規格に置き換えられていますが、そのセクション一覧は読みやすいチェックリストとして残っています）、テスト種別の分類（機能、リグレッション、スモーク／サニティ、構造）、リスクベーステスト（可能性 × 影響度で優先順位と深さを決定）、要件カバレッジのトレーサビリティ、ケース設計技法（BVA、同値分割、デシジョンテーブル、状態遷移テスト、ペアワイズ選択、ネガティブテスト）を含めます。一般論としての「テスト」ではなく、この製品の対象範囲に即して策定してください。リサーチ機能が利用できない場合は、動作、レベル、基準を捏造せず、検証が必要な前提として明示してください。

ステップ 4：プロジェクトに必要な機能レベルを選択する — 最も低コストで立証できるレベル

すべてのプロジェクトがすべてのレベルを必要とするわけではありません。カバレッジマップの各行を、それを立証できる最も低コストのレベルに対応付けます。純粋なロジックにはユニット、モジュール／サービス間の接続にはインテグレーション、ユーザーに見えるフローにはシステム／E2E、PRD のビジネス基準には受け入れテストを選びます。必要な種類（リグレッション、スモーク／サニティ）を意識して選択します。含めるレベル／種類と省くレベル／種類は、それぞれ根拠を示します。説明のない省略はカバレッジの欠落です。

ステップ 5：カタログにリスクの重みを付け、テストケースを設計する — 深さはリスクに応じて決め、総当たりの組み合わせにはしない

網羅的なテストは不可能です。対象範囲に含まれる各領域について、発生可能性 x 影響度を評価し、テストの深さと順序を決めるリスク優先度を設定します。

• すべての振る舞い／エラーに、少なくとも 1 つの追跡可能なケースを用意します（カバレッジの最低基準）。
• 高リスク領域ではケース数を増やします。適切な技法を選びます。BVA（境界値とその前後）、同値分割（クラスごとに 1 つ）、デシジョンテーブル（組み合わせ規則）、状態遷移テスト（状態を持つ振る舞い）、ペアワイズ選択（相互作用するパラメーターが多数ある場合 → 2^N ではなく、すべてのペアを網羅）、ネガティブテスト（正確に期待されるエラー）。
• 単純／低リスクの領域は、正常系のみにします。
• ML／確率的な振る舞い：固定された出力がないモデルに対して、決定論的な「期待結果」を定めるのは適切ではありません（テストオラクル問題）。このようなケースは、名前を明示したデータセットでのメトリクスしきい値（例：「eval-v3 で precision >= 0.92」）またはメタモルフィック関係にします。「モデルの精度が高い」のような基準は使いません。必要に応じて、ドリフト／公平性のチェックを追加します。（詳細：references/case-design-and-nonfunctional.md。）
• 自動化が費用対効果に見合わない場合は、スクリプト化したケースをチャーターを定めた、時間制限付きの探索的テスト（SBTM）セッションで補完してもかまいません。場当たり的にクリックするのではなく、チャーター（ミッション＋対象領域＋時間枠）を定めます。

規模の目標は、プロジェクトのリスクに応じた網羅性であり、入力の全組み合わせを総当たりすることではありません（N 個のスイッチがあるモジュールには 2^N 通りの組み合わせがあります。リスク評価とペアワイズで網羅します）。規模はアーキタイプに応じて調整します。薄い CLI なら少数のケースにし、不要なレベルは統合します。大規模な UI 製品なら、多数のケースが必要です。

ステップ 6：非機能テスト、環境とテストデータ、検証可能な基準、実行可能なケース

• 非機能テスト（適正な規模で実施）。NFR／アーキタイプが必要とする非機能テストの種類ごとに、検証可能なアプローチと数値／標準の目標値を示します。パフォーマンス（負荷プロファイル＋p95／スループット＋ツール）、セキュリティ（脅威に基づくテスト項目）、アクセシビリティ（WCAG 2.2 AA）、ユーザビリティ、互換性（マトリックス）、i18n／l10n が対象です。必要な NFR がない種類は、1 行の注記を添えて省略します。レイテンシの数値を捏造してはいけません。（詳細：references/case-design-and-nonfunctional.md。）
• **環境とテストデータ。**各レベルで、実行場所と必要なデータを明記します。テストデータは計画的に管理します。合成データと本番マスキング済みデータの使い分け、PII／PHI の取り扱い（テスト環境に未加工の本番 PII を持ち込まないこと）、フィクスチャのライフサイクル（プロビジョニング＋リセット）、データ駆動テストを含みます。（詳細：references/execution-and-amend.md。）
• 開始／終了（「完了」）基準は、観察／測定可能なものにします。終了基準は「すべての高優先度ケースが合格し、すべての振る舞いに合格した追跡可能なケースがあり、必要な非機能目標を満たし、未解決の Critical／High 不具合がないこと」とします（不具合の深刻度と優先度の尺度、および未解決不具合のしきい値を定めることで、「完了」を機械的に判定できます）。「テストの結果が良さそう」では不十分です。
• カタログの各ケースには、明示的な事前条件、単一アクションで動詞から始まる手順（Navigate、Enter、Click、Validate — 1 ステップにつき 1 アクション）、観察可能な期待結果（ネガティブケースでは正確なメッセージ／エラー、ML ケースではメトリクスのゲート）、およびカバレッジマップの行へのトレース先を記載します。

ステップ 7：引き渡す前に基準を満たしているか自己確認する

以下のすべてを確認します（これが reviewing-test-plan ゲートで確認される基準です。作成者とゲートで共有し、内容にずれが生じないようにします）。

1. 網羅性 — feature-spec のすべての振る舞い／AC、および api-spec のすべての操作／エラーに、追跡可能なケースが 1 件以上あります。ケースのない振る舞いはありません。
2. 適切な機能テストレベル — ユニット／統合／E2E／受け入れテストがプロジェクトに適しています。省略するものにはすべて理由があり、黙って省略されていません。
3. テスト可能な開始／終了基準 — 観察または測定が可能です。終了基準はカバレッジの最低基準と未解決不具合のしきい値に結び付いています。カバレッジは単なるコードカバレッジ率ではなく、要件／リスクを基準に表現されています。
4. 環境とテストデータを指定 — 各レベルで、実行場所、必要なデータ、その準備／リセット方法、機密データの取り扱いを明記しています。
5. 各ケースが実行可能で追跡可能 — 前提条件、単一アクションの手順、観察可能な期待結果（ML の場合はメトリクスのしきい値）、および追跡先が含まれています。
6. リスクを優先し、リスクに応じて重み付け — 発生可能性 × 影響度に基づいています。テストの深さはリスクに応じており（高リスクでは境界値／異常系も対象）、あらゆる組み合わせの総当たりではありません。薄すぎず、過剰に水増しされてもいません。
7. 創作した内容がない — すべてのケースは実際の上流仕様に追跡できます。不足がある場合は、振る舞いや目標を創作せず、明示的な仮定として記載しています。
8. プロジェクトの類型に見合った規模 — プロジェクトに適した規模で、組み合わせ爆発を起こすほど網羅的でも、骨組みだけでもありません。プロジェクトに必要な範囲を網羅しています。
9. 非機能テスト — 該当する各非機能テスト種別に、確認可能なアプローチと数値／標準の目標値が定められています。該当しない種別は、注記を添えて省略されています。
10. 改訂（改訂する場合） — 変更範囲が明確で、全体を書き直さずに編集しています。カバレッジマップを再追跡し、影響度＋リスクに基づいて回帰テストセットを選定し、計画をバージョン管理し、変更履歴を記録し、置き換えられたケースに印を付けています（ステップ 8）。

入力不足のゲート： システムが満たすべき振る舞いについて、調査しても、テスト可能なケースにできるだけの信頼できる仮定を立てられない場合は、ケースを創作せず、ブロッカー（「振る舞いの仕様が不十分です — テスト可能にする前に、プロダクト／エンジニアリング上の判断が必要です」）として提示します。

ステップ 8：承認済みの計画を改訂する（バージョン管理された差分 — 全体を書き直さない）

既存の計画＋変更要求（上流の振る舞いの変更／追加／削除、または発見された不具合）を受け取った場合：

1. 変更範囲を特定します — 影響を受けるカバレッジマップの行、ケース、レベル／種別、基準、または非機能テストのアプローチを特定します。
2. 全体を書き直さず、編集します — 影響を受ける行／ケースをその場で改訂します。
3. カバレッジマップを再追跡します — 変更／追加された振る舞いは対応する行を再マッピングし、削除された振る舞いは対応するケースを廃止します。カバレッジの整合性を保ちます（ケースのない振る舞いも、対応先のないケースもありません）。
4. 影響度＋リスクに基づいて回帰テストセットを選定します — 変更箇所に関係するため再実行が必要な既存ケース（影響度に基づく）と、高リスク／高価値のケース（リスクに基づく）を選びます。すべてでも、ゼロでもなく、選定理由を明記します。
5. 不具合 → 回帰テストケース — 発見された不具合ごとに、問題を起こした振る舞いに追跡できる新しいケースを 1 件以上追加し、同じ不具合が気付かれないまま再発しないようにします。
6. 計画自体のバージョンを更新し、変更履歴（誰が／いつ／何を／なぜ）を記録し、置き換え／廃止されたケースに印を付けます（黙って削除しません）。詳しくは references/execution-and-amend.md を参照してください。

ルール

厳守事項（決して違反しないこと）：

• すべてのケースの根拠を上流の仕様に置きます。 各ケースは、feature-spec の動作／AC、または api-spec の操作／エラーにたどれる必要があります。根拠のないケースや作り出したケースを設けず、ケースのない動作も認めません。
• カタログはリスクに応じて重み付けし、総当たりにはしません。 各動作につき最低1ケースを設けます。リスクの高い領域には、適切な手法（BVA／EP／デシジョンテーブル／状態遷移／ペアワイズ）を使って、より多くのケース（境界値、否定ケース）を設けます。全パラメーターの組み合わせを総当たりすることは避けます。
• 開始基準と終了基準はテスト可能にします。 それぞれが観察または測定可能で、読者が機械的に判定できる必要があります。終了基準はカバレッジの最低水準と未解決不具合のしきい値に結び付けます。「テストの結果が良好」は基準になりません。
• 各ケースは実行可能で、追跡可能である必要があります。 前提条件、単一の動作を示す動詞で始まる手順、観察可能な期待結果（否定ケースでは正確なエラー、ML では名前付きデータセットに対する指標としきい値。「モデルが動作する」は不可）、およびトレース先を記載します。
• 非機能テストは対象を絞り、曖昧にしません。 必要な非機能テストの各種類には、検証可能なアプローチと数値または規格による目標（パフォーマンスの p95、WCAG 2.2 AA、脅威セット）を設定します。該当しない種類は、その旨を注記して省略します。
• 決して捏造しません。 完全に見せるために動作、レベル、基準、NFR／レイテンシー目標を作り出してはいけません。根拠がない場合は、明示的に仮定として示します。
• 変更はバージョン管理された差分として反映します。 変更依頼があった場合は、新たに書き直すのではなく既存の内容を編集し、カバレッジを再トレースして、影響とリスクに基づいて回帰テスト対象を選び、バージョンと変更履歴を更新し、置き換えられた内容にはその旨を記載します。全体を黙って書き直してはいけません。
• 重複させず、組み立てます。 セクション構成はテンプレートツールから採用し、このスキルではその内容を埋める方法を示します。競合する構成を貼り付けてはいけません。
• 仕様ではケースを、戦略では方針を示します。スクリプトや手順書にはしません。 テストする内容とケースを指定します。実行可能なテストコード（後工程）や、リリース手順書に記載する運用上の検証は含めません。

推奨事項（変更可能）：

• 「包括的」は目指す範囲を示しますが、適切な規模に保ちます。カバレッジの網羅性はリスクに応じて確保し、文章量を増やすことを目的にしません。小規模な CLI では、不要な非機能テストのマトリクス、回帰テスト、変更履歴は省略します。
• 代表値には BVA と同値分割を、組み合わせルールにはデシジョンテーブルを、状態を持つ動作には状態遷移カバレッジを、パラメーター間に相互作用がある場合は総当たりよりペアワイズを優先します。
• 単純な割合よりも、カバレッジマップに基づく終了基準（「すべての動作に、合格した追跡可能なケースがある」など）を優先します。

注意点

• カタログが膨れ上がります。 入力の組み合わせをすべて列挙すると、組み合わせ爆発を起こして保守できなくなります。リスクに応じて規模を決めます。動作ごとに1ケースを用意し、追加ケース（境界値、負のケース）は発生可能性 x 影響度が高い場合に限ります。パラメーターが相互作用する場合はペアワイズテストを使います。
• ケースがない動作。 機能仕様の動作や api-spec のエラーを省くと、ゲートで検出されるカバレッジの抜けが生じます。まずカバレッジマップを作成し、すべてのケースを対応付けます。
• 曖昧な終了基準。 「安定したと感じたら完了」では評価できません。すべての基準を観測可能な形（ケースの合格、欠陥の解消、カバレッジマップの行の網羅）で表現します。
• ML 機能で「モデルの精度は高い」。 非決定的なシステムには固定のオラクルがないため、決定的な合否ケースは実行できません。名前を明記したデータセットで指標のしきい値を定めます（またはメタモーフィック関係を使います）。
• パフォーマンスやアクセシビリティの目標を捏造する。 NFR がなければ、レイテンシやスループットの数値を勝手に設定しません。上流に記載がないことを記録し、該当タイプを省略（または明示）します。アクセシビリティの標準目標は WCAG 2.2 AA です。
• コードカバレッジを終了ゲートにする。 「カバレッジ90％」はスクリプトで計測する指標であり、操作できるうえ、各動作がテストされているかどうかも示しません。要件とリスクのカバレッジを基準にゲートを設定します。
• 計画を描き直して改訂する。 小さな変更のたびに計画全体を再生成すると、監査証跡と回帰テスト選定の規律が失われます。範囲を絞り、既存の内容を編集して、バージョンを付けます。
• 計画とテストコード／リリース用ランブックを混同する。 スクリプトは後続の実装です。ランブックのスモークテストではこの計画の終了基準を再利用しますが、運用手順は別です。これは戦略とカタログとして保ちます。
• テンプレートの概要をそのまま書き直す。 セクション一覧を再構成すると、テンプレートツールと重複し、内容にずれが生じます。判断を加えて各セクションを埋めます。

対比例 — 仕様不足（表面上は準拠）と実行可能（自己検出に使ってください）：

項目	仕様不足（却下）	実行可能（採用）
カバレッジ	「ログイン機能をテストします。」	「FS-§3.1 ログイン と api-spec の POST /sessions（200、401、429）を、それぞれカバレッジマトリクスの e2e 行と unit 行に対応付けます。」
レベル	「テストを書きます。」	「トークンハッシャーは unit、セッションストアは integration、ログインフローは e2e でテストします。」
カタログの詳細度	「入力の組み合わせをすべてテストします。」	「TC-001 有効なログイン（正常系）；TC-002 誤ったパスワード -> 401；TC-003 空のパスワード（境界値）；TC-004 6回目の試行 -> 429（高リスクの負のケース）。」
ML ケース	「レコメンダーの精度を検証します。」	「事前条件：データセット rec-eval-v2。期待値：precision@10 >= 0.85 AND p95 latency <= 120ms。追跡先：FS-§4.2。」
非機能要件	「高速でアクセシブルであること。」	「パフォーマンス：同時ユーザー500人、p95 <= 200ms（k6）。アクセシビリティ：WCAG 2.2 AA — キーボード操作 + コントラスト + フォーカス表示。」
終了基準	「安定するまでテストします。」	「優先度 High のケースがすべて合格し、未解決の Critical／High 欠陥がなく、カバレッジマップの全行に合格ケースがあること。」

記入内容が左側の列のように、どのプロジェクトにも当てはまる、レベルがない、追跡可能性がない、目標値がないものなら、まだ完了ではありません。

アンチパターン

• 「徹底するために、入力のあらゆる組み合わせをテストします。」 組み合わせ爆発の罠です。直積ではなく、リスクとペアワイズに基づいて規模を決めます。
• 「正常系だけで十分です。」 リスクの高い動作には、境界値と異常系のケースが必要です。想定されるエラーを明記してください。
• 「妥当そうなパフォーマンス目標を考えて設定します。」 NFR がなければ、数値を捏造せず、ギャップを示して該当タイプを省きます。
• 「モデルも決定論的な合否判定で問題ありません。」 ML には、名前を明記したデータセットに対するメトリックと閾値、または変形関係が必要です。固定の期待値ではありません。
• 「この変更に合わせて計画全体を再生成します。」 改訂は、影響とリスクに基づいて回帰テストを選定する、対象を絞ったバージョン管理付きの差分です。
• 「この機会にテストスクリプトも書きます。」 実行可能なコードは後続の実装です。このドキュメントではテストケースを仕様化します。
• 「よさそうなら終了します。」 合格ケースとクローズ済みの不具合に基づき、基準を機械的に評価できる形で表現してください。
• 「概要は自分で書きます。」 テンプレートツールと重複します。構成はテンプレートツールから取得してください。
• 「調査は省きます。テストのことはわかっています。」 調査はテスト理論ではなく、この製品のテストレベル、リスクの重み付け、非機能目標、ケース設計の根拠になります。

出力

Step 7 の基準を満たす包括的なテスト計画です（完全で追跡可能なカバレッジ、適切な機能テストレベル、不具合のしきい値に紐づいたテスト可能な開始・終了条件、環境とテストデータ管理、メトリックと閾値を伴う ML ケースを含む実行可能かつ追跡可能なケース、組み合わせ爆発ではなくリスクに応じた設計、根拠のある数値目標を持つ非機能テスト、捏造なし、適切な分量、改訂時には影響とリスクに基づいて回帰テストを選定した対象限定のバージョン管理付き差分）。成果物はテキスト形式です。戦略の説明に、カバレッジマトリクス、非機能マトリクス、Markdown 形式のテストケース一覧を組み合わせます。TestRail/Xray のエクスポートではありません。また、この手法と基準は媒体に依存しません（将来テスト管理のバックエンドが変わっても、変わるのは媒体のみです）。抽象的な利用者は、計画を実行するテスター、終了基準を再利用する後続のリリースランブック、同じ基準を検証する reviewing-test-plan ゲートです。この計画は、feature-spec と api-spec（存在する場合は PRD / NFRs にも）依存します。その構成はテンプレートツールに由来し、このスキルが提供するのは内容の品質です。

関連項目

• テスト計画テンプレートツール（例：content-template-gateway） — このスキルが埋めるセクション構成（非機能、バージョン管理、テストデータ、回帰テスト用の項目を含む）を提供します。組み合わせて使用し、概要を重複して記載しないでください。
• ディープリサーチ機能 — 確立された実務手法（ISTQB のレベル、ISO/IEC/IEEE 29119 の構成、リスクベースドテスト、要件トレーサビリティ、BVA/EP/デシジョンテーブル/状態遷移/ペアワイズ、ML テスト、WCAG 2.2 AA）を計画の根拠として示します。
• reviewing-test-plan — 対となるゲートです。同じカバレッジとテスト可能性の基準を検証します（10 条件のチェックリストは、このスキルの Step 7 と一元管理されています）。作成とレビューの基準にずれが生じないようにしてください。
• feature-spec-authoring と api-spec-authoring の各スキル — ケースが検証する上流の動作契約を作成します。
• PRD と architecture-doc / NFRs — 上流のコンテキストです。終了基準が紐づく受け入れ条件と、§10 のテストで検証する非機能目標を提供します。
• release-runbook スキル — 下流の運用検証です。この計画の終了基準を再利用する、別個のドキュメントです。

段階的な開示

• references/case-design-and-nonfunctional.md — テストケース設計手法（BVA、同値分割、デシジョンテーブル、状態遷移テスト、ペアワイズ）と探索的テスト／SBTM、非機能テストの分類（種類ごとのアプローチ＋目標）、ML／確率的なテストケース設計（メトリック閾値、メタモルフィックテスト、ドリフト／公平性）。
• references/execution-and-amend.md — テストデータ管理（合成データとマスキング済みデータ、PII／PHI、フィクスチャ、データ駆動）、欠陥の重大度／優先度＋終了条件との関連、修正／回帰テスト選択の手順。
• references/sources.md — 手法と品質基準の調査出典。ガイダンスの出典を監査する場合のみ読み込みます。

本文の上限

• description は 1,024 文字以下（agentskills.io の上限）。
• 本文は約 500 行／5,000 トークン以下。
• 詳細な内容は references/ に置き、必要に応じて読み込みます。

変更履歴

• 1.1.0（2026-06-15）— 本番環境向けに再構成：反復／修正の手法（ステップ 8）、数値目標を含む非機能テストの分類（パフォーマンス／セキュリティ／WCAG 2.2 AA／互換性／国際化）、ML／確率的なテストケース設計（メトリック閾値／メタモルフィックテスト）、テストケース設計手法（BVA／EP／デシジョンテーブル／状態遷移／ペアワイズ）＋探索的テスト／SBTM、カバレッジ基準の分類＋カバレッジに基づく終了条件、テストデータ管理、欠陥の重大度と優先度の違いを追加しました。ISO/IEC/IEEE 29119 を現行標準として明記（IEEE 829 は後継規格に置き換え）。詳細は新たに追加した 2 つの references/ ファイルに移しました。加算的な変更です。入力契約とテキスト成果物は変更していません。reviewing-test-plan 1.1.0（10 条件の基準）と情報源を共有しています。
• 1.0.0（2026-06-05）— 初回レビュー済みリリース。