qa-test-plan

QA テスト計画

完了した要件成果物から、構造化された QA テスト計画を生成します。ビジネス要件とユーザーペルソナに直接対応するテストスイートを作成するため、QA チームは各デリバリータイムラインの QA ラウンドで何をテストすべきかを正確に把握できます。

前提条件

• {base_directory}/requirements/business-requirements.yaml（/business-requirements-interview の出力）
• {base_directory}/requirements/technical-requirements.yaml（/technical-requirements-interview の出力）

使用方法

/qa-test-plan [base-directory]

ディレクトリが指定されていない場合は、カレントディレクトリで requirements/business-requirements.yaml を探して自動検出します。

見つからない場合は、ユーザーに「要件ドキュメントはどこにありますか？」と尋ねます。

処理を続行する前に、ユーザーがパスを指定するまで待ちます。base_directory として保存します。

プロセス

ステップ 1：ベースディレクトリの特定と要件の読み込み

ディレクトリパラメーターが指定されていない場合は、カレントディレクトリに requirements/business-requirements.yaml が存在するか確認します。

• 見つかった場合は、カレントディレクトリを base_directory として使用します
• 見つからない場合は、「要件ドキュメントはどこにありますか？」と尋ね、ユーザーの回答を待ちます

base_directory が決まったら、{base_directory}/requirements/ から両方の要件ファイルを読み込みます。以下を抽出します。

business-requirements.yaml から：

• 機能要件とユーザーストーリー
• ユーザーペルソナと主なユースケース
• 成功基準と指標
• 既知の制約とエッジ条件

technical-requirements.yaml から：

• API の範囲（エンドポイント、入力、出力）
• 認証と認可のモデル
• 非機能要件（パフォーマンス目標、稼働時間 SLA）
• データモデルの制約（必須フィールド、一意性、形式）
• セキュリティ要件

ステップ 2：テストスイートの特定

テスト対象範囲をテストスイートに分類します。各スイートは、個々のマイルストーンではなく、一貫性のある機能領域に対応します。要件から直接スイートを導き出し、ソースドキュメントにない機能を作り出さないでください。

検討する標準的なスイートのカテゴリ（該当するもののみ含めます）：

カテゴリ	根拠となる要件
認証	技術要件に記載された認証モデル
コアユーザーフロー	ユーザーペルソナ＋機能要件
データ検証	データモデルの制約
API コントラクト	技術要件に記載された API 設計
権限とロール	認可モデル
エラー処理	要件のエッジケース＋API のエラー状態
パフォーマンス	非機能のパフォーマンス目標
セキュリティ	セキュリティ要件
統合	技術要件に記載された外部依存関係

ステップ 3：スイートごとにテストケースを作成する

各スイートについて、以下を網羅するテストケースを作成します。

• Positive — 正常系、想定される成功結果
• Negative — 無効な入力、未認証のアクセス、必須フィールドの欠落
• Edge — 境界値、空の状態、同時操作、大きなペイロード
• Security — インジェクション、未認証アクセスの権限昇格、トークン／セッションの不正使用
• Performance — 想定負荷時の応答時間（目標が指定されている場合のみ）

各テストケースには、以下を含める必要があります。

• id — スイート内で一意の ID（例：tc-auth-001）
• name — テスト内容を平易な言葉で説明したもの
• type — positive | negative | edge | security | performance
• priority — high | medium | low
  • high：成功基準、または名前が挙げられたペルソナの主要なユースケースを網羅します
  • medium：二次的なフローまたは検証ルールを網羅します
  • low：一般的なユーザーへの影響が少ない、エッジケースや例外的なケースを網羅します
• preconditions — テストの実行前に必要なシステムの状態
• steps — 番号付きの具体的な操作
• expected_result — 検証可能な具体的な結果
• requirement_refs — このケースで検証するビジネス要件／技術要件の ID
• tags — フィルタリング用の任意のラベル（例：[smoke, regression, auth]）

ステップ 4：カバレッジを算出する

カバレッジ指標を算出します。

• 機能カバレッジ — high 優先度のテストケースが 1 つ以上ある、名前の付いた機能要件の割合
• ペルソナカバレッジ — 主要なユースケースに positive テストケースがあるユーザーペルソナの割合
• 非機能カバレッジ — NFR カテゴリごとの真偽値（パフォーマンス、セキュリティなど）。テストケースが 1 つ以上存在すること

テストケースがない機能要件は、カバレッジのギャップとして報告します。

ステップ 5：qa-test-plan.yaml を生成する

{base_directory}/delivery/qa-test-plan.yaml に書き込みます。

ディレクトリが存在しない場合は作成します。

mkdir -p {base_directory}/delivery

ステップ 6：ギャップ分析

ファイルの生成後、以下をインラインで報告します。

## QA Test Plan Gap Analysis

**Project:** [name]
**Test Suites:** [n]
**Total Test Cases:** [n] ([n] high / [n] medium / [n] low)
**Functional Coverage:** [n]% ([n]/[n] requirements have high-priority cases)
**Persona Coverage:** [n]% ([n]/[n] personas covered)

**NFR Coverage:**
[✓ / ✗] Performance tests present
[✓ / ✗] Security tests present
[✓ / ✗] Integration tests present

**Gaps:**
- [requirement or persona with no coverage, if any]

**Recommendations:** [none / list]

出力形式

qa-test-plan.yaml スキーマ

出力ドキュメントには、version、project、generated、sources（参照ファイルのパス）、summary（優先度別のテスト件数、カバレッジ指標）、および test_suites（各スイートに id（ts-slug）、name、description、requirement_refs、test_cases を含む）が含まれます。各テストケースには、id（tc-suite-nnn）、name、type（positive/negative/edge/security/performance）、priority（high/medium/low）、preconditions、steps、expected_result、requirement_refs、および任意の tags が含まれます。

すべてのフィールド、カバレッジの算出ルール、テストケースの構成を含む完全なドキュメント仕様については、references/output-spec.md を参照してください。

完全な例については、references/example.yaml を参照してください。

出力例

QA テストプランの完全なサンプルについては、references/example.yaml を参照してください。