test-strategy-doc

テスト戦略ドキュメントスキル

機能仕様書、PRD、またはシステムの説明から、対象範囲、テストの種類、リスク領域、カバレッジ要件、優先順位付きのテストケース概要を網羅したテスト戦略を作成します。

必要な入力

以下の情報が提供されていない場合は、確認してください。

• テスト対象の機能またはシステム（仕様書やPRDを貼り付けるか、平易な言葉で説明してください）
• 技術スタック（言語とフレームワーク。例：TypeScript + React、Python + FastAPI）
• 既存のテストカバレッジ（例：「ユニットテストはありますが、E2Eテストはありません」「すでに Jest + Playwright を使用しています」「これから始めます」）
• デプロイ頻度（例：継続的デプロイ／週次リリース／四半期ごと。自動化と手動のどちらが必要かに影響します）
• リスクレベル（低／中／高／重大。テストの深さとカバレッジ要件に影響します）
• スケジュール（いつリリースする必要があるか。優先順位に影響します）
• チームの状況（誰がテストを担当するか。開発者／専任 QA／両方）

出力形式

1. テスト対象範囲

対象範囲内：

• [テスト対象となる具体的な機能]
• [対象となる統合ポイント]
• [対象となるユーザー向けフロー]

対象範囲外：

• [意図的にテストしない内容とその理由]
• [他のチームが担当する依存関係]

前提条件：

• [モック化されたサービス、テストデータの利用可能性など、テスト戦略で真として扱う前提]

2. リスク評価

まず最もリスクの高い領域を特定します。これらの領域が、テストの深さとカバレッジを決定します。

領域	リスクレベル	理由	テストの優先度
[例：決済処理]	高	資金の移動、規制	P0 — 徹底的にテスト
[例：ユーザー認証]	高	セキュリティ境界	P0 — 徹底的にテスト
[例：メール通知]	中	外部依存関係	P1 — 正常系 + 重要な失敗ケース
[例：UI の文言変更]	低	見た目のみで、元に戻せる	P2 — スモークテストのみ

3. テストの種類とカバレッジ

ユニットテスト

• 内容： 個々の関数やメソッドを分離してテストします
• 作成者： 開発者
• カバレッジ目標： [例：新規コードの行カバレッジ 80%／重要な処理経路の 100%]
• ツール： [例：Jest、pytest、go test]
• この機能で重点を置く領域： [ユニットテストでカバーする必要がある具体的なロジック]

統合テスト

• 内容： サービス間のやり取り、データベース操作、API コントラクトをテストします
• 作成者： 開発者／QA
• カバレッジ目標： [すべての正常系 + 重要な失敗ケース]
• ツール： [例：Supertest、pytest + testcontainers]
• 重点領域： [リスクのある具体的な統合。例：サードパーティ API、DB スキーマの変更]

エンドツーエンドテスト

• 内容： ブラウザー／クライアントからデータベースまでの重要なユーザージャーニーをテストします
• 作成者： QA／開発者
• カバレッジ目標： [上位 N 件のユーザージャーニー。内容を列挙してください]
• ツール： [例：Playwright、Cypress、Selenium]
• 重点領域： [最も重要な 3～5 件のユーザーフロー]

パフォーマンステスト (リスク評価表のいずれかの行でパフォーマンスがリスク要因になっている場合は、全体のリスクレベルにかかわらず含めてください)

• 内容： 負荷、ストレス、またはレイテンシーのテスト
• 目標： [具体的な数値。例：p95 < 200ms で 200 req/sec]
• ツール： [例：k6、Locust、JMeter]

セキュリティテスト (リスクが高以上の場合のみ含めてください)

• 内容： この機能に関連する OWASP Top 10 のチェック
• 重点項目： [認証の回避、インジェクション、データ漏えい]
• ツール： [例：OWASP ZAP、手動のペネトレーションテスト、Snyk]

4. テストケースの概要

優先度順に並べた具体的なテストケース：

P0 — マージ前に合格必須：

テストケース	種類	期待される結果
[例：ユーザーが有効な認証情報でログインできる]	E2E	[ダッシュボードにリダイレクトされ、セッションが作成される]
[例：無効なログインでは401が返される]	インテグレーション	[エラーメッセージが表示され、セッションは作成されない]
[例：パスワードが平文で保存されることはない]	ユニット	[DBにbcryptハッシュが保存される]

P1 — リリース前に合格必須：

テストケース	種類	期待される結果
[例：DBが停止している場合、ログインが適切に失敗する]	インテグレーション	[ユーザーにわかりやすいエラーが表示され、503が返される]
[例：ログイン失敗が5回続くとレート制限がブロックする]	インテグレーション	[429が返され、アカウントにフラグが付けられる]

P2 — 合格が望ましいが、既知の問題を記録したうえでリリース可能：

テストケース	種類	期待される結果
[例：ログインページがモバイルで正しく表示される]	E2E	[レイアウトがデザインと一致する]

5. テストデータの要件

• [必要な具体的なテストデータ — 例：さまざまな状態のテストユーザーアカウント]
• [必要な外部サービスのスタブまたはモック]
• [データベースのシードデータ要件]
• [PIIに関する懸念と、テストデータでの対処方法]

6. 完了の定義

テストは、以下を満たした時点で完了です：

• すべてのP0テストケースに合格している
• すべてのP1テストケースに合格している
• コードカバレッジが定められた目標を満たしている
• 重大または高深刻度の未解決バグがない
• パフォーマンス目標を達成している（該当する場合）
• セキュリティチェックが完了している（該当する場合）

品質チェック

• リスク表が記入され、テストの優先順位に反映されている（一般論で埋められていない）
• リスク評価表の「P0 — 徹底的にテスト」対象の各行に、対応するP0テストケースが少なくとも1つある
• 「対象外」セクションに少なくとも1つの具体的な除外項目が記載されている（空欄のままにされていない）
• 各テスト種別に具体的なツールが記載されている（「何らかのテストフレームワーク」ではない）
• 完了の定義が測定可能である（「QAが問題ないと判断したらテスト完了」ではない）

アンチパターン

• テストの優先順位を決めるリスク表なしにテスト戦略を作成しないでください — 一般的なカバレッジ目標は戦略ではありません
• 「対象外」セクションを空欄のままにしないでください — すべてのテスト戦略で、テスト対象外の項目とその理由を明示する必要があります
• 各テスト種別に具体的なツールを記載せずに指定しないでください — 「何らかのテストフレームワーク」では実行に移せません
• 測定できない完了の定義を設定しないでください — 「QAが問題ないと判断したら」は完了基準ではありません
• 対応するP0テストケースなしにP0のリスク領域を作成しないでください — リスク評価はテストカバレッジに対応させる必要があります

使用例

• 「[機能]のテスト戦略を作成して」＋[仕様書またはPRDを貼り付ける]
• 「[システム]のテスト計画を作成して」
• 「[機能]はどのようにテストすればよいですか？」
• 「このスプリントのQA計画が必要です」
• 「[X]にはどのようなテストが必要ですか？」