# Test Scope Definition

> 実装・変更に対して何をどこまでテストすべきかを定義する。テスト種別・対象・優先度・合否基準を整理し、テスト不足による手戻りを防ぐ。テスト計画を立てるときに使う。

- Skill: `thinkyou0714/test-scope-definition` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/test-scope-definition`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/test-scope-definition/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/test-scope-definition

---


## Purpose

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

## Use When

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

## Inputs

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

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

## Output Contract

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

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

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

| テスト種別 | 対象 | 優先度 | 合否基準 |
|---|---|---|---|
| ユニットテスト | （関数・モジュール名） | 必須 / 推奨 / 任意 | （どういう状態をパスとするか） |
| 統合テスト | （エンドポイント・フロー名） | 必須 / 推奨 / 任意 | |
| E2E テスト | （ユーザーシナリオ名） | 必須 / 推奨 / 任意 | |
| 手動確認 | （確認手順名） | 必須 / 推奨 / 任意 | |
| パフォーマンステスト | （対象処理名） | 必須 / 推奨 / 任意 | |

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

## Review Lens

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

## Instructions

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

## Guardrails

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

## LAB Cross-Check

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | Webhook / n8n フローのテストが含まれているか |
| データ / 認証 / ログ | — | 認証・RLS・ログ出力のテストが含まれているか |
| 実装 / 運用フロー | — | CI での自動実行が可能なスコープか |
| 非エンジニア理解可能性 | — | 合否基準を説明できる言葉か |
| 会員共有 / 再利用耐性 | — | テストスコープ定義の形式が他変更にも転用できるか |
| 他LLM移植耐性 | — | 評価基準が Claude 固有に依存していないか |

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

## Handoff Notes

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

## Further Reading

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