Test Scope Definition

Purpose

「テストを書いたが重要な箇所が抜けていた」「テストが多すぎて保守できない」を防ぐ。 変更の種別とリスクに応じて、最小限かつ十分なテストスコープを定義する。

Use When

• 実装・変更の前後にテスト方針を決めたい場合
• レビュー前にテストカバレッジを確認したい場合
• テストを書く優先度をつけたい場合
• 施工AIへのタスク委譲時にテスト要件を明示したい場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 変更内容: テスト対象となる実装・変更の説明
• 変更種別: 新機能追加 / バグ修正 / リファクタリング / DB マイグレーション / API 変更
• 影響範囲: 変更が波及する機能・API・DB テーブル
• 既存テスト: 現在のテストファイル・テスト種別・カバレッジ概要
• テストツール: 使用するテストフレームワーク・ツール

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: このテストスコープを左右する核心的な判断軸
2. 根拠: その論点をそう判断した理由
3. テストスコープ定義: 種別・対象・優先度・合否基準の一覧
4. 含意: このスコープの網羅度と残存リスクの意味
5. 改善案: テストコストを下げつつカバレッジを上げる工夫
6. 代替案: フルテストが困難な場合のリスクベース優先付け
7. 判断材料: 「このスコープで進む / スコープを縮小する / スコープを拡大する」を選ぶための情報

テストスコープ定義 フォーマット

テスト種別は実際に使用するもののみ記載すること。

Review Lens

• 目的妥当性: テストスコープが変更リスクに対して適切か
• 範囲の過不足: 重要なユーザーシナリオが抜けていないか / 過剰テストになっていないか
• 中長期リスク: テストが増えすぎて保守コストが上がらないか
• LAB全体との整合性: 既存テスト構成（Vitest / Playwright 等）と整合しているか
• 非エンジニア理解可能性: 合否基準が非技術者に説明できるか
• 他LLM移植耐性: テスト種別の定義が Claude 固有の解釈に依存していないか

Instructions

1. 変更種別に応じてテスト戦略の重点を変える（新機能→正常系、バグ修正→再現ケース、リファクタ→既存動作保証）
2. 変更の影響範囲を元にテスト対象を列挙する
3. 各テスト対象に優先度（必須 / 推奨 / 任意）を付ける
4. 「必須」のテストが全通過しない場合はマージ・デプロイ不可とする基準を明示する
5. E2E は重要なユーザーシナリオに絞る（網羅的 E2E は保守コストが高い）
6. 手動確認が必要な場合はチェックリスト形式で手順を提示する
7. 最終スコープ判断は人間に委ねる

Guardrails

• 「テストがないが影響軽微だから任意」で必須テストを任意に格下げしない
• カバレッジ数値を目的にしない。重要な動作の保証を目的にする
• バグ修正には必ず再現テストを「必須」に含める
• DB マイグレーション変更にはロールバック後の状態確認テストを含める
• 外部 API 呼び出しはモックと実 API テストを分けて明示する

LAB Cross-Check

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

• 要件: テストスコープの定義（種別・対象・優先度・合否基準）
• 成功条件: 必須テストが全通過し、手動確認チェックリストが完了した状態
• 失敗条件: 必須テストが1件でも失敗している状態
• 実行範囲: テストを書く / 実行するファイル・ディレクトリ
• 影響範囲: テスト追加によって変更が必要な設定ファイル・CI 定義
• ロールバック方針: テスト追加後に CI が壊れた場合の切り戻し
• コスト比較: テスト実装コスト vs テストなしで問題発覚した場合のコスト

Further Reading

• implementation-gate skill — テストスコープ確認を含む実装着手前チェック
• change-impact-scan skill — テスト対象の影響範囲洗い出し
• patch-readiness skill — パッチ適用前のテスト準備確認
• docs/CONTEXT.md — 技術スタック・テストツール