analyzing-test-strategy

name: analyzing-test-strategy description: テストピラミッド設計、テスト種別の定義、カバレッジ目標の設定を含むテスト戦略を策定。「テスト戦略を決めたい」「テスト計画を立てたい」「カバレッジ目標を設定したい」「テストピラミッドを設計したい」「TDD/BDD の方針を決めたい」といった場面で発動する。テスト戦略を先に策定することで、開発中の「何をどこまでテストすべきか」の迷いを排除する。

テスト戦略策定

アーキテクチャパターンに適合するテスト形状（ピラミッド型・ダイヤモンド型・逆ピラミッド型）を選択し、テスト戦略を策定する。

テスト戦略はアーキテクチャと表裏一体。レイヤードアーキテクチャならピラミッド型、マイクロサービスならダイヤモンド型が適合しやすい。テスト形状を間違えると、テストの実行時間が爆発するか、品質保証が不十分になる。

参照ドキュメントとテンプレート

種類	パス	備考
ガイド	@docs/reference/テスト戦略ガイド.md	テスト戦略の進め方詳細
テンプレート	@docs/template/設計.md	編集禁止。コピーして使用する
入力	@docs/requirements/requirements_definition.md	要件定義
入力	@docs/requirements/business_usecase.md	ビジネスユースケース
入力	@docs/requirements/system_usecase.md	システムユースケース
入力	@docs/requirements/user_story.md	ユーザーストーリー
入力	@docs/design/architecture_backend.md	バックエンドアーキテクチャ
入力	@docs/design/architecture_frontend.md	フロントエンドアーキテクチャ
成果物	`docs/design/test_strategy.md`	テスト戦略

テスト形状の選択

アーキテクチャパターンとシステム特性に基づいてテスト形状を選択する。形状の選択理由を明記せよ。

ピラミッド型（ユニット重視）: ビジネスロジックが複雑でドメイン層が厚い場合に適する。ユニットテストを土台に高速なフィードバックを得る
ダイヤモンド型（統合テスト重視）: マイクロサービスや外部連携が多い場合に適する。サービス間の結合点を重点的にテストする
逆ピラミッド型（E2E 重視）: UI 中心のアプリケーションやレガシーシステムの保護に適する。ただし実行時間とメンテナンスコストが高いことを認識せよ

テストレベルの定義

各テストレベルの責務を明確に定義する。テストレベル間で検証内容が重複すると、テストスイート全体の実行時間が不必要に増える。

ユニットテスト: 単一クラス/関数の振る舞いを検証する。外部依存はモックする
統合テスト: コンポーネント間の連携を検証する。DB やメッセージキューとの結合を含む
E2E テスト: ユーザーシナリオに基づいてシステム全体を検証する
受け入れテスト: ユーザーストーリーの受入条件を検証する

テスト戦略の策定

具体的な数値目標とツール選定を行う。曖昧な「十分にテストする」ではなく、測定可能な基準を設定せよ。

カバレッジ目標: テストレベルごとのカバレッジ目標を設定する（例: ユニット 80%、統合 60%）
テストツールの選定: 技術スタックに適合するテストツールを選定する
CI/CD との連携: テスト実行のタイミングと失敗時の振る舞いを定義する

トレーサビリティの確保

要件からテストケースまでの追跡を可能にする。「この機能はどのテストで保証されているか」を常に回答可能にせよ。

要件とテストケースのマッピング: ユーザーストーリーの受入条件とテストケースを対応づける

作成の進め方

アーキテクチャドキュメント（バックエンド・フロントエンド）を確認する
@docs/reference/テスト戦略ガイド.md を読み込む
テスト形状→テストレベル→カバレッジ目標→ツール選定の順に策定する
docs/design/test_strategy.md として出力する

途中から再開する場合

既存の docs/design/test_strategy.md がある場合は、まずその内容を確認する。不足しているテストレベルの定義や更新が必要な部分のみを修正する。

Example:

ユーザー: 「テスト形状はピラミッド型に決めた。カバレッジ目標を設定したい」
回答: 既存の test_strategy.md のテスト形状を確認し、
      ピラミッド型に基づいてテストレベルごとのカバレッジ目標を設定する。
      ユニット→統合→E2E の順に目標値と測定方法を定義する。

注意事項

アーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
テスト戦略はアーキテクチャパターンに適合させる。パターンとの不整合は無駄なテストを生む
TDD/BDD の適用を検討し、開発プロセスとテスト戦略を一体化する
タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）