テスト設計の抜け漏れ防止を実現するモデル駆動型テスト設計スキル。生成AIにテスト項目を「列挙」させる前に、抜け漏れを検出できる構造（モデルとカバレッジ基準）を先に作らせる。Use when: テスト設計、テスト計画作成、QA開始前、機能実装後のテスト作成、テストの網羅性を確保したい時、「テスト漏れがないか不安」と感じた時。
/plugin marketplace add CAPHTECH/claude-marketplace/plugin install caphtech-plugin@caphtech-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/audit-checklist.mdreferences/coverage-criteria.mdreferences/model-templates.md生成AIの限界を理解する：AIは「それらしい網羅」を"生成"するのは得意だが、「何が未生成か」を"証明"するのは苦手。
対策：列挙前に「モデル化」と「監査」を挿入し、抜けを"見える化"する。
現実には状態空間・入力空間・環境差分が巨大で"全組み合わせを全件テスト"は成立しない。 実務的な「抜け漏れがない」の定義：
Phase 0: コンテキストパック収集
↓
Phase 1: 要求の棚卸し（REQ-xxx）
↓
Phase 2: モデル化（5つのモデル）
↓
Phase 3: カバレッジ基準策定
↓
Phase 4: テスト条件ツリー（TCND-xxx）
↓
Phase 5: 監査（複数視点）
↓
Phase 6: テスト項目生成（TEST-xxx）
↓
Phase 7: トレーサビリティ検証
↓
Phase 8: 差分運用
AIに渡す情報を固定する。情報が散らばるとモデルが不安定になり抜けが増える。
| カテゴリ | 収集内容 |
|---|---|
| システム概要 | 何をするシステムか |
| 対象範囲 | スコープ内/スコープ外の明示 |
| ユースケース | 主要ユーザーフロー |
| 依存 | 外部API、決済、認証、Push、DB、OS機能 |
| データ制約 | 入力バリデーション、桁、形式 |
| 権限・ロール | ユーザー種別とアクセス制御 |
| 非機能 | 性能、セキュリティ、可用性、監査ログ、アクセシビリティ |
| 運用 | 障害時対応、監視、リリース、バックアウト |
| 既知障害 | 過去のインシデント、ヒヤリハット |
| 受入基準 | Doneの定義 |
警告: ここが薄いとAIは「一般論のテスト」になり、固有リスクを取り逃がす。
目的: 要求を「テスト可能な形」に変換。AIにいきなりテストを書かせない。
| REQ ID | 種類 | 要求概要 | 受入条件（観測可能） |
|--------|------|---------|-------------------|
| REQ-001 | 機能 | ログイン機能 | 正しい資格情報でセッション発行 |
| REQ-002 | 非機能 | レスポンス2秒以内 | 95%タイルで2秒以下 |
| REQ-003 | 制約 | パスワード8文字以上 | 7文字以下でエラー |
要求一覧とは別に「不明点・矛盾・仮定」セクションを設ける。これがないと仮定が埋め込まれたまま進む。
核心: テストは列挙ではなく、モデルから導出する。
詳細テンプレートは references/model-templates.md を参照。
機能 → サブ機能 → 操作/イベント → 期待結果
主要状態と遷移イベントを明確化。
例：未ログイン → ログイン中 → トークン期限切れ → 退会済み
エンティティ、属性、制約、整合性、更新規則。PIIや秘匿データの扱い。
API一覧、リクエスト/レスポンス、エラーコード、リトライ方針、タイムアウト、冪等性。
失敗モード → 影響 → 検出方法 → 予防/緩和 → テスト観点
「何を満たすと網羅と言えるか」を明示。これがないとAIは"それっぽい数"で止まる。
詳細は references/coverage-criteria.md を参照。
| 基準 | 定義 |
|---|---|
| 要求カバレッジ | 全REQに対して少なくとも1つのTCND |
| 状態遷移カバレッジ | 主要遷移（正常/異常）をすべて通す |
| 入力空間カバレッジ | 同値分割＋境界値 |
| エラー網羅 | 外部IFの代表的失敗（timeout/5xx/4xx/不正payload） |
| 品質特性カバレッジ | 性能・セキュリティ・可用性・監査ログ・アクセシビリティ |
| 環境カバレッジ | OS/端末/ネットワーク/言語/権限（必要な範囲） |
テスト項目を直接書かせず、まずテスト条件の木を作らせる。
Feature A
├── 正常系
│ ├── TCND-001: 基本フロー成功
│ └── TCND-002: オプション付きフロー
├── 入力バリデーション
│ ├── TCND-003: 必須項目欠落
│ └── TCND-004: 形式不正
├── 状態依存
│ ├── TCND-005: 状態S1からの操作
│ └── TCND-006: 状態S2からの操作
├── 外部IF失敗
│ ├── TCND-007: timeout
│ └── TCND-008: 5xx応答
├── セキュリティ
│ ├── TCND-009: 権限不足
│ └── TCND-010: 不正操作
├── 性能/負荷
│ └── TCND-011: 同時接続100件
└── 監査ログ
└── TCND-012: 操作記録確認
TCND-xxx のIDを付与(UNKNOWN) ラベルをつけて残す（消さない）核心: 生成AIを「批判側」に回す。役割を変えると見つかる抜けが増える。
あなたはテスト監査人（生成した本人ではない体）。
以下のテスト条件ツリーを監査し、抜け漏れの可能性を列挙せよ。
詳細チェックリストは references/audit-checklist.md を参照。
必須観点:
監査は最低2回、異なる視点で行う：
ツリーの「葉」から生成する。葉IDがあるので抜けが追える。
| TEST ID | TCND | REQ | 前提条件 | 入力 | 期待結果 |
|---------|------|-----|---------|-----|---------|
| TEST-001 | TCND-001 | REQ-001 | 未ログイン状態 | 有効なID/PW | セッション発行 |
| TEST-002 | TCND-003 | REQ-003 | - | 7文字PW | エラー表示 |
(UNKNOWN) はテストを捏造せず、質問・前提の形で残す| REQ ID | TCND | TEST | ステータス |
|--------|------|------|----------|
| REQ-001 | TCND-001, TCND-002 | TEST-001, TEST-002 | カバー済 |
| REQ-002 | - | - | **未対応** |
| REQ-003 | TCND-003 | TEST-003 | カバー済 |
未対応 = REQに紐づくTCND/TESTがない → 抜け確定TESTのみ存在 = REQ紐づきなし → 探索テストか不要かを判断仕様変更時に再発しないための運用。
requirements.md: 要求一覧（REQ-xxx）+ 不明点・仮定models/: 5つのモデル（Feature tree、状態、データ、外部IF、リスク）coverage-criteria.md: このプロジェクトのカバレッジ基準test-conditions.md: テスト条件ツリー（TCND-xxx）audit-report.md: 監査結果（抜け候補と対応）test-cases.md: テスト項目一覧（TEST-xxx）traceability.md: 要求↔テスト対応表references/model-templates.md: モデル化テンプレートreferences/coverage-criteria.md: カバレッジ基準詳細references/audit-checklist.md: 監査チェックリスト