Skills
skills/caphtech/claude-marketplace/test-design-audit

test-design-audit

SKILL.md

Test Design Audit（ELD統合版テスト設計監査）

ELDとの関係

本スキルはELD（Evidence-Loop Development）のGroundフェーズにおける テスト設計を体系化する。

ELD Loop: Sense → Spec → Predict-Light → Change → Ground → Record
                                              ↑
                                    test-design-audit

Law/Term → テスト条件への導出を行い、Evidence Ladderでの接地を保証する。

核心原則

生成AIの限界を理解する：AIは「それらしい網羅」を"生成"するのは得意だが、「何が未生成か」を"証明"するのは苦手。

対策：列挙前に「モデル化」と「監査」を挿入し、抜けを"見える化"する。

ELD的強化：Law/Termを要求の源泉とし、Evidence Ladderでカバレッジを階層化する。

抜け漏れの定義

現実には状態空間・入力空間・環境差分が巨大で"全組み合わせを全件テスト"は成立しない。 実務的な「抜け漏れがない」の定義：

  1. 要求カバレッジ: スコープ内の要求（機能/非機能/制約/既知リスク）に対してテスト条件が対応づいている
  2. 未知の明示: 未知（不明点）と仮定が明示され、未確定領域がテスト外になっていない

ワークフロー概要

Phase 0: コンテキストパック収集
    ↓
Phase 1: 要求の棚卸し（REQ-xxx）+ Law/Term対応付け
    ↓
Phase 2: モデル化（5つのモデル + Law/Term視点）
    ↓
Phase 3: カバレッジ基準策定 + Evidence Ladder
    ↓
Phase 4: テスト条件ツリー（TCND-xxx）+ Law Grounding
    ↓
Phase 5: 監査（複数視点 + Law違反チェック）
    ↓
Phase 6: テスト項目生成（TEST-xxx）+ Grounding Map連携
    ↓
Phase 7: トレーサビリティ検証 + Law/Term紐付け
    ↓
Phase 8: 差分運用

Phase 0: コンテキストパック収集

AIに渡す情報を固定する。情報が散らばるとモデルが不安定になり抜けが増える。

必須収集項目

カテゴリ 収集内容
システム概要 何をするシステムか
対象範囲 スコープ内/スコープ外の明示
ユースケース 主要ユーザーフロー
依存 外部API、決済、認証、Push、DB、OS機能
データ制約 入力バリデーション、桁、形式
権限・ロール ユーザー種別とアクセス制御
非機能 性能、セキュリティ、可用性、監査ログ、アクセシビリティ
運用 障害時対応、監視、リリース、バックアウト
既知障害 過去のインシデント、ヒヤリハット
受入基準 Doneの定義

警告: ここが薄いとAIは「一般論のテスト」になり、固有リスクを取り逃がす。

Phase 1: 要求の棚卸し + Law/Term対応付け

目的: 要求を「テスト可能な形」に変換し、Law/Termと対応付ける。

ELD統合: Law/Term対応付け

要求をELDのLaw/Termに対応付けることで、テストの根拠を明確化する。

対応パターン 説明
REQ → Law 要求が既存Lawの検証に対応
REQ → Term 要求がTermの境界検証に対応
REQ → 新Law候補 新しいLawの発見（/eld-modelへ）

出力フォーマット

| REQ ID | 種類 | 要求概要 | 受入条件（観測可能） | Law/Term |
|--------|------|---------|-------------------|----------|
| REQ-001 | 機能 | ログイン機能 | 正しい資格情報でセッション発行 | LAW-auth-valid-credential |
| REQ-002 | 非機能 | レスポンス2秒以内 | 95%タイルで2秒以下 | LAW-response-time-sla |
| REQ-003 | 制約 | パスワード8文字以上 | 7文字以下でエラー | TERM-password |

種類の分類

  • 機能（Functional）→ 多くの場合Law（Invariant/Pre/Post）に対応
  • 非機能（Non-functional）→ Policy Lawに対応
  • 制約（Constraint）→ Termの境界条件に対応
  • 運用（Operational）→ Policy Lawに対応
  • 法令・規約（Regulatory）→ S0 Lawに対応
  • UX（User Experience）→ 新Law候補として検討

必須セクション

要求一覧とは別に「不明点・矛盾・仮定」セクションを設ける。これがないと仮定が埋め込まれたまま進む。

Law/Termが未定義の場合は (NEW-LAW) または (NEW-TERM) ラベルを付け、 /eld-model で定義する。

Phase 2: モデル化 + Law/Term視点

核心: テストは列挙ではなく、モデルから導出する。Law/Termを軸に整理する。

詳細テンプレートは references/model-templates.md を参照。

ELD統合: モデルとLaw/Termの対応

モデル Law/Termとの対応
機能分解 各機能の不変条件（Invariant）をLaw化
状態モデル 状態遷移制約をLaw化、状態をTermとして定義
データモデル エンティティをTerm化、整合性制約をLaw化
外部IFモデル API契約をPre/Post条件としてLaw化
リスクモデル 失敗モードを「Law違反パターン」として整理

2-1. 機能分解（Feature Tree）+ Invariant

機能 → サブ機能 → 操作/イベント → 期待結果 → [関連Law]

各機能に関連するLaw（不変条件）を紐付ける。

2-2. 状態モデル（State Machine）+ 状態遷移Law

主要状態と遷移イベントを明確化。

例：未ログイン → ログイン中 → トークン期限切れ → 退会済み

Law化: 状態遷移制約（「退会済み→ログイン中」は不可など）

2-3. データモデル + Term定義

エンティティ、属性、制約、整合性、更新規則。PIIや秘匿データの扱い。

Term化: 主要エンティティをTerm Cardとして定義（境界、観測写像）

2-4. 外部IFモデル + Pre/Post条件

API一覧、リクエスト/レスポンス、エラーコード、リトライ方針、タイムアウト、冪等性。

Law化: API契約をPre条件（入力制約）/Post条件（出力保証）として明示

2-5. リスクモデル + Law違反パターン

失敗モード → 影響 → 検出方法 → 予防/緩和 → テスト観点

ELD観点: 各失敗モードを「どのLawが破られるか」で分類

Phase 3: カバレッジ基準策定 + Evidence Ladder

「何を満たすと網羅と言えるか」を明示。これがないとAIは"それっぽい数"で止まる。

詳細は references/coverage-criteria.md を参照。

ELD統合: Evidence Ladder

ELDの「証拠の梯子」を基準に、テストの深さを階層化する。

Level 検証内容 対象 テスト種別
L0 静的整合 全Law/Term 型チェック、Lint
L1 単体での成立 S0-S2 Law ユニットテスト、Property-based test
L2 連携での成立 S0-S1 Law 統合テスト、E2Eテスト
L3 異常時の維持 S0 Law 失敗注入、Fuzz testing
L4 実運用での成立 S0-S1 Law 本番Telemetry、監視

重要: L0だけで完了扱いしない。S0 LawはL2以上必須。

Law Severity別の必須レベル

Severity 必須レベル 推奨レベル
S0（致命的） L0 + L1 + L2 + L3 L4
S1（重要） L0 + L1 + L2 L3 + L4
S2（中程度） L0 + L1 L2
S3（低） L0 L1

基本基準

基準 定義 Evidence Ladder
要求カバレッジ 全REQに対して少なくとも1つのTCND -
Law接地カバレッジ 全Lawが必須レベルを達成 L0-L4
状態遷移カバレッジ 主要遷移（正常/異常）をすべて通す L1-L2
入力空間カバレッジ 同値分割＋境界値（Termの境界） L1
エラー網羅 外部IFの代表的失敗（timeout/5xx/4xx/不正payload） L2-L3
品質特性カバレッジ 性能・セキュリティ・可用性・監査ログ・アクセシビリティ L2-L4
環境カバレッジ OS/端末/ネットワーク/言語/権限（必要な範囲） L2

Phase 4: テスト条件ツリー作成 + Law Grounding

テスト項目を直接書かせず、まずテスト条件の木を作らせる。 Law/Termの接地（Grounding）を意識した構造にする。

ELD統合: Law Grounding視点

テスト条件をLaw/Termの接地レベル（Evidence Ladder）で分類する。

Feature A [LAW-xxx]
├── L1: ユニットテスト条件
│   ├── TCND-001: 基本フロー成功 [L1]
│   └── TCND-002: 境界値検証 [L1]
├── L2: 統合テスト条件
│   ├── TCND-003: 外部IF連携成功 [L2]
│   └── TCND-004: 状態遷移正常 [L2]
├── L3: 失敗注入テスト条件
│   ├── TCND-005: timeout時の回復 [L3]
│   └── TCND-006: 5xx応答時のフォールバック [L3]
└── L4: 運用観測条件
    └── TCND-007: Telemetry記録確認 [L4]

構造（ELD統合版）

Feature A [LAW-feature-a-invariant]
├── 正常系
│   ├── TCND-001: 基本フロー成功 [L1] [LAW-xxx]
│   └── TCND-002: オプション付きフロー [L2] [LAW-xxx]
├── 入力バリデーション [TERM-input-xxx]
│   ├── TCND-003: 必須項目欠落 [L1]
│   └── TCND-004: 形式不正（境界値） [L1]
├── 状態依存 [LAW-state-transition]
│   ├── TCND-005: 状態S1からの操作 [L2]
│   └── TCND-006: 状態S2からの操作 [L2]
├── 外部IF失敗 [LAW-external-if-contract]
│   ├── TCND-007: timeout [L3]
│   └── TCND-008: 5xx応答 [L3]
├── セキュリティ [LAW-security-xxx]
│   ├── TCND-009: 権限不足 [L2]
│   └── TCND-010: 不正操作 [L3]
├── 性能/負荷 [LAW-performance-sla]
│   └── TCND-011: 同時接続100件 [L2-L4]
└── 監査ログ [LAW-audit-trail]
    └── TCND-012: 操作記録確認 [L4]

必須ルール

  • 各葉に TCND-xxx のIDを付与
  • どのREQに対応するか（REQ-xxx）を必ず紐づける
  • どのLaw/Termを検証するかを紐づける
  • Evidence Ladderのレベル（L1-L4）を明示
  • 不明点がある葉は (UNKNOWN) ラベルをつけて残す（消さない）

Phase 5: 監査 + Law違反チェック

核心: 生成AIを「批判側」に回す。役割を変えると見つかる抜けが増える。 ELD的追加: Law/Termの接地状況を監査する。

監査役プロンプト

あなたはテスト監査人（生成した本人ではない体）。
以下のテスト条件ツリーを監査し、抜け漏れの可能性を列挙せよ。
特に以下の観点で監査：
1. 全てのLaw/Termに対してテスト条件が存在するか
2. Law Severityに応じたEvidence Ladderレベルを満たしているか
3. Law違反時の動作がテストされているか

監査観点

詳細チェックリストは references/audit-checklist.md を参照。

必須観点:

  • 要求カバレッジ欠落（REQに紐づかない/未対応REQ）
  • Law/Term接地カバレッジ欠落（Law/Termに紐づかない/未接地）
  • Evidence Ladder未達成（S0 LawがL2未満など）
  • 状態遷移の未カバー
  • エラー処理、復旧、冪等性、再試行、タイムアウト
  • Law違反時の動作テスト欠落
  • 競合（同時操作、二重送信）、順序逆転、遅延
  • 権限/認可、ログ、監査、個人情報
  • 互換性/環境差分
  • テストデータ（境界値、相関制約）
  • "未知/仮定"が放置されてテスト不能になっていないか

ELD統合: Law接地監査

/eld-ground-verify を使用してLaw/Termの接地状況を検証:

/eld-ground-verify LAW-xxx

結果:
✅ L0: 型チェック通過
✅ L1: Unit Test (3/3)
❌ L2: Integration Test なし
❌ L3: 失敗注入テストなし
⚠️ L4: Telemetry設定済み（未検証）

推奨アクション:
- L2: 統合テスト TCND-xxx を追加
- L3: timeout/5xx時の動作テストを追加

複数視点での監査（必須）

監査は最低2回、異なる視点で行う：

  1. 1回目: QA視点（一般的な抜け漏れ）
  2. 2回目: Law接地視点（ELD固有）
  3. 3回目（推奨）: 以下から選択
    • 運用担当視点
    • セキュリティ担当視点
    • 性能担当視点
    • アクセシビリティ担当視点

Phase 6: テスト項目生成 + Grounding Map連携

ツリーの「葉」から生成する。葉IDがあるので抜けが追える。 ELD的追加: Grounding Mapと連携してLaw/Termの接地を保証する。

出力フォーマット（ELD統合版）

| TEST ID | TCND | REQ | Law/Term | Level | 前提条件 | 入力 | 期待結果 |
|---------|------|-----|----------|-------|---------|-----|---------|
| TEST-001 | TCND-001 | REQ-001 | LAW-auth | L1 | 未ログイン状態 | 有効なID/PW | セッション発行 |
| TEST-002 | TCND-003 | REQ-003 | TERM-password | L1 | - | 7文字PW | エラー表示 |
| TEST-003 | TCND-007 | REQ-004 | LAW-external-if | L3 | 外部API停止中 | 任意 | フォールバック動作 |

ELD統合: Grounding Map更新

テスト項目をGrounding Mapに反映:

# grounding-map.yaml
laws:
  LAW-auth-valid-credential:
    severity: S0
    verification:
      unit:
        - TEST-001  # ← test-design-auditから追加
        - TEST-002
      integration:
        - TEST-010
      runtime:
        - AuthService.validateCredential
    observation:
      telemetry:
        - auth.success_rate
      alert:
        - auth_failure_spike

ルール

  • 各TESTは必ず1つ以上のTCNDに紐づく
  • 各TESTは必ず1つ以上のLaw/Termに紐づく
  • Evidence Ladderのレベルを明示
  • 期待結果は観測可能な形（UI表示/状態/ログ/APIレスポンス）
  • (UNKNOWN) はテストを捏造せず、質問・前提の形で残す

Phase 7: トレーサビリティ検証 + Law/Term紐付け

対応表の作成（ELD統合版）

| REQ ID | Law/Term | TCND | TEST | Level | ステータス |
|--------|----------|------|------|-------|----------|
| REQ-001 | LAW-auth | TCND-001, TCND-002 | TEST-001, TEST-002 | L1, L2 | カバー済 |
| REQ-002 | LAW-perf | - | - | - | **未対応** |
| REQ-003 | TERM-password | TCND-003 | TEST-003 | L1 | カバー済 |

ELD統合: Law/Term接地状況表

| Law/Term | Severity | 必須Level | 現在Level | TCND | ステータス |
|----------|----------|-----------|-----------|------|----------|
| LAW-auth | S0 | L0-L3 | L0-L2 | TCND-001,002 | **L3未達** |
| LAW-perf | S1 | L0-L2 | L0 | - | **未接地** |
| TERM-password | S1 | L0-L1 | L1 | TCND-003 | ✅ 達成 |

抜け検出

  • 未対応 = REQに紐づくTCND/TESTがない → 抜け確定
  • 未接地 = Law/Termに紐づくTCND/TESTがない → ELD的抜け確定
  • Level未達 = 必須Evidence Ladderレベルに未到達 → 追加テスト必要
  • TESTのみ存在 = REQ/Law紐づきなし → 探索テストか不要かを判断

Phase 8: 差分運用

仕様変更時に再発しないための運用。

手順

  1. 仕様差分（REQの追加/変更/削除）を特定
  2. Law/Term差分（新規Law/変更されたLaw）を特定
  3. 影響範囲（どのFeature/State/Data/IF/Lawに波及するか）を分析
  4. 影響のあるTCND/TESTだけを更新
  5. 対応表を更新して「未対応REQゼロ」「未接地Law/Termゼロ」を維持

最小セット（時間がない場合）

  • (T1) 要求一覧（REQ-xxx）を作成し、不明点を明示、Law/Term対応付け
  • (T2) 主要な観点（正常系・異常系・境界・セキュリティ）でテスト条件を作成、Evidence Ladder明示
  • (T3) 監査を1回実施（Law接地視点を含める）
  • (T4) トレーサビリティ表で未対応REQと未接地Law/Termを確認

出力物

  • requirements.md: 要求一覧（REQ-xxx）+ 不明点・仮定 + Law/Term対応
  • models/: 5つのモデル（Feature tree、状態、データ、外部IF、リスク）+ Law/Term視点
  • coverage-criteria.md: このプロジェクトのカバレッジ基準 + Evidence Ladder
  • test-conditions.md: テスト条件ツリー（TCND-xxx）+ Law Grounding
  • audit-report.md: 監査結果（抜け候補と対応）+ Law接地監査
  • test-cases.md: テスト項目一覧（TEST-xxx）+ Grounding Map連携
  • traceability.md: 要求↔テスト対応表 + Law/Term接地状況表
  • grounding-map.yaml: Law/Term → Test/Telemetry対応表（ELD共通）

ELD関連スキル

スキル 用途
/eld ELD統合開発手法のメイン
/eld-model Law/Term発見・Card作成
/eld-ground-verify Law/Termの接地状況検証・成果物評価
/systematic-test-design 体系的テスト設計（ユニットテスト＋PBT統合）

参照

  • references/model-templates.md: モデル化テンプレート
  • references/coverage-criteria.md: カバレッジ基準詳細
  • references/audit-checklist.md: 監査チェックリスト
  • references/eld-integration.md: ELD統合ガイド
Weekly Installs
2
Repository
caphtech/claude…ketplace
First Seen
4 days ago
Security Audits
Gen Agent Trust HubPass
SocketPass
SnykPass
Installed on
mcpjam2
claude-code2
replit2
junie2
windsurf2
zencoder2