| name | test-design-audit |
| description | 要求トレーサビリティ（REQ→TCND→TEST）とカバレッジモデルによりテスト設計の抜け漏れを防止する監査スキル。モデル化・複数視点監査で体系的に検証する。Use when: テスト設計、テスト計画作成、QA開始前、「テスト漏れがないか不安」と感じた時 |
Test Design Audit（テスト設計監査）
核心原則
生成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: 差分運用
Phase 0: コンテキストパック収集
AIに渡す情報を固定する。情報が散らばるとモデルが不安定になり抜けが増える。
必須収集項目
| カテゴリ | 収集内容 |
|---|
| システム概要 | 何をするシステムか |
| 対象範囲 | スコープ内/スコープ外の明示 |
| ユースケース | 主要ユーザーフロー |
| 依存 | 外部API、決済、認証、Push、DB、OS機能 |
| データ制約 | 入力バリデーション、桁、形式 |
| 権限・ロール | ユーザー種別とアクセス制御 |
| 非機能 | 性能、セキュリティ、可用性、監査ログ、アクセシビリティ |
| 運用 | 障害時対応、監視、リリース、バックアウト |
| 既知障害 | 過去のインシデント、ヒヤリハット |
| 受入基準 | Doneの定義 |
警告: ここが薄いとAIは「一般論のテスト」になり、固有リスクを取り逃がす。
Phase 1: 要求の棚卸し
目的: 要求を「テスト可能な形」に変換する。
出力フォーマット
| REQ ID | 種類 | 要求概要 | 受入条件（観測可能） |
|--------|------|---------|-------------------|
| REQ-001 | 機能 | ログイン機能 | 正しい資格情報でセッション発行 |
| REQ-002 | 非機能 | レスポンス2秒以内 | 95%タイルで2秒以下 |
| REQ-003 | 制約 | パスワード8文字以上 | 7文字以下でエラー |
種類の分類
- 機能（Functional）: 機能要件、主要フロー
- 非機能（Non-functional）: 性能・可用性などの品質特性
- 制約（Constraint）: 入力形式・桁数などの境界条件
- 運用（Operational）: 障害対応・監視・リリース手順
- 法令・規約（Regulatory）: コンプライアンス要件
- UX（User Experience）: ユーザー体験に関する要求
必須セクション
要求一覧とは別に「不明点・矛盾・仮定」セクションを設ける。これがないと仮定が埋め込まれたまま進む。
Phase 2: モデル化
核心: テストは列挙ではなく、モデルから導出する。
詳細テンプレートは references/model-templates.md を参照。
2-1. 機能分解（Feature Tree）
機能 → サブ機能 → 操作/イベント → 期待結果
2-2. 状態モデル（State Machine）
主要状態と遷移イベントを明確化。
例：未ログイン → ログイン中 → トークン期限切れ → 退会済み
制約: 不正な状態遷移（「退会済み→ログイン中」は不可など）を明示する。
2-3. データモデル
エンティティ、属性、制約、整合性、更新規則。PIIや秘匿データの扱い。
2-4. 外部IFモデル
API一覧、リクエスト/レスポンス、エラーコード、リトライ方針、タイムアウト、冪等性。
契約: API契約を事前条件（入力制約）/事後条件（出力保証）として明示する。
2-5. リスクモデル
失敗モード → 影響 → 検出方法 → 予防/緩和 → テスト観点
Phase 3: カバレッジ基準策定
「何を満たすと網羅と言えるか」を明示。これがないとAIは"それっぽい数"で止まる。
詳細は references/coverage-criteria.md を参照。
基本基準
| 基準 | 定義 |
|---|
| 要求カバレッジ | 全REQに対して少なくとも1つのTCND |
| 状態遷移カバレッジ | 主要遷移（正常/異常）をすべて通す |
| 入力空間カバレッジ | 同値分割＋境界値 |
| エラー網羅 | 外部IFの代表的失敗（timeout/5xx/4xx/不正payload） |
| 品質特性カバレッジ | 性能・セキュリティ・可用性・監査ログ・アクセシビリティ |
| 環境カバレッジ | OS/端末/ネットワーク/言語/権限（必要な範囲） |
Phase 4: テスト条件ツリー作成
テスト項目を直接書かせず、まずテスト条件の木を作らせる。
構造
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を付与
- どのREQに対応するか（REQ-xxx）を必ず紐づける
- 不明点がある葉は
(UNKNOWN) ラベルをつけて残す（消さない）
Phase 5: 監査
核心: 生成AIを「批判側」に回す。役割を変えると見つかる抜けが増える。
監査役プロンプト
あなたはテスト監査人（生成した本人ではない体）。
以下のテスト条件ツリーを監査し、抜け漏れの可能性を列挙せよ。
監査観点
詳細チェックリストは references/audit-checklist.md を参照。
必須観点:
- 要求カバレッジ欠落（REQに紐づかない/未対応REQ）
- 状態遷移の未カバー
- エラー処理、復旧、冪等性、再試行、タイムアウト
- 競合（同時操作、二重送信）、順序逆転、遅延
- 権限/認可、ログ、監査、個人情報
- 互換性/環境差分
- テストデータ（境界値、相関制約）
- "未知/仮定"が放置されてテスト不能になっていないか
複数視点での監査（必須）
監査は最低2回、異なる視点で行う：
- 1回目: QA視点（一般的な抜け漏れ）
- 2回目（推奨）: 以下から選択
- 運用担当視点
- セキュリティ担当視点
- 性能担当視点
- アクセシビリティ担当視点
Phase 6: テスト項目生成
ツリーの「葉」から生成する。葉IDがあるので抜けが追える。
出力フォーマット
| TEST ID | TCND | REQ | 前提条件 | 入力 | 期待結果 |
|---------|------|-----|---------|-----|---------|
| TEST-001 | TCND-001 | REQ-001 | 未ログイン状態 | 有効なID/PW | セッション発行 |
| TEST-002 | TCND-003 | REQ-003 | - | 7文字PW | エラー表示 |
| TEST-003 | TCND-007 | REQ-004 | 外部API停止中 | 任意 | フォールバック動作 |
ルール
- 各TESTは必ず1つ以上のTCNDに紐づく
- 期待結果は観測可能な形（UI表示/状態/ログ/APIレスポンス）
(UNKNOWN) はテストを捏造せず、質問・前提の形で残す
Phase 7: トレーサビリティ検証
対応表の作成
| 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紐づきなし → 探索テストか不要かを判断
Phase 8: 差分運用
仕様変更時に再発しないための運用。
手順
- 仕様差分（REQの追加/変更/削除）を特定
- 影響範囲（どのFeature/State/Data/IFに波及するか）を分析
- 影響のあるTCND/TESTだけを更新
- 対応表を更新して「未対応REQゼロ」を維持
最小セット（時間がない場合）
- (T1) 要求一覧（REQ-xxx）を作成し、不明点を明示
- (T2) 主要な観点（正常系・異常系・境界・セキュリティ）でテスト条件を作成
- (T3) 監査を1回実施
- (T4) トレーサビリティ表で未対応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: 監査チェックリスト- 関連（任意）: Law/Term起点で接地状況を検証したい場合は
/eld-ground verify も参照可能
