test-case-review

テストケースレビュー（test-case-review）

「これらのテストケースは、本当に適切にテストできているのか」に答える、事後の独立したレビューです（作成時のセルフレビューは test-case-writing のフェーズ4で行います）。

• 入力：既存のケースファイル（markmap + Schema。ない場合は先に抽出できます）、PRD／要件モデル、コードリポジトリ
• 出力（ファイルへの保存）：ケースファイルを直接修正（修正後に Schema を再抽出）＋レビュー記録（ファイル末尾に付録として追加）
• レビュー記録の内容：不足／冗長／誤り／高リスクの未カバー項目を、TC 番号ごとに列挙

使用する場面

• 既存のテストケース資産（以前からあるケース、他者が作成したケース）が、十分にカバーされ、実行可能かを確認する
• AI が生成したテストケースをレビューする（カバレッジと実行可能性の両面から確認）
• 作成者から独立したレビュー結果が必要な場合（作成時のセルフレビューでは代替できません）

使用しない場面

• ゼロからテストケースを作成する場合 → test-case-writing
• テストケース作成中にセルフレビューする場合 → test-case-writing のフェーズ4（4A／4B の二層レビュー）
• エンドツーエンドのパイプラインにおけるレビュー工程 → qa がこの skill を調整しますが、ユーザーが本 skill を直接実行する場合にも適用できます
• コード変更後に回帰テストの範囲を選定する場合 → regression-testing

ワークフロー

1. テスト可能なポイントの基準を作成する（分母）

カバレッジレビューには妥当な分母が必要です。次の優先順位で基準を選びます。

1. 人手で注釈されたテスト可能なポイントの一覧（存在する場合は最も信頼できます）
2. 要件モデル + ユーザーと共同で確認したテスト可能なポイントの一覧（レビュー開始前に列挙し、漏れがないかユーザーに確認します）
3. 元の入力ソースのみがある場合 → PRD／コードからテスト可能なポイントの一覧を独自に抽出し、「未確認」と明記して、納品時にユーザーへ確認を依頼します

分母のないカバレッジ率は、自分で自分の答案を採点するようなものです。基準がない場合はその旨を正直に伝え、カバレッジ率を捏造しないでください。

2. カバレッジレビュー（この時点で ../core/coverage.md を実行：コア7次元をすべて個別に確認 + 横断的な実行可能性）

• コア7次元を個別に確認します：機能のメインフロー／入力検証／逆操作とライフサイクル／状態遷移／データの一貫性／ドキュメントに暗黙的に含まれる要件／コードレビューでの指摘（コードがある場合）。拡張次元（8–19）は coverage.md の「次元選択クイックリファレンス」に従ってプロジェクトの種類に応じて選び、機械的にすべてを確認しないでください（実施の強度は利用者に応じて調整します。詳細は同ファイルの冒頭を参照）
• 状態遷移次元の再確認時は ../core/methods/state-machine.md を読み込みます。その「状態集合 × イベント集合 × 遷移辺」の一覧に沿って、各辺のテストケースカバレッジを照合します（各辺に少なくとも1件、さらに不正な遷移／並行競合／逆向きの辺の3種類を必ず追加）。テストケースが状態機械に沿って整理されていない場合は、状態機械を逆算して独自に抽出してから照合し、「カバーされているように見える」状態を防ぎます
• 二次交差（../core/testing-principles.md 第3節）：書き込みパス × 検証ルール、失敗 × 再試行、識別子 × 重複——既存のテストケースで最もよく見られる体系的な漏れです
• 基準に照らして各ポイントを確認します：カバー済み（TC 番号）／未カバー／カバー済みだがアサーションに誤りがある／冗長（複数のケースが同じポイントをテスト）／無効（対象の要件をテストしていない）

3. 実行可能性レビュー（この時点で ../core/executability.md のすべての確認項目を実行）

各テストケースを8つの厳格な基準で確認し、特に次の点を重点的にチェックします。

• プレースホルダーデータ（{xxx}、「何らかのデータ」）、存在しない入口、曖昧な判定（「機能が正常」）、非同期処理に制限時間がない、アサーションが過剰に厳しい、前提条件を取得できず TODO もない、本文にコードの内部実装が含まれる、導入用の4項目がない

4. 正確性レビュー（PRD／コードがある場合）

• テストケースの期待結果が PRD のルール／コードの実装と一致しているかを確認します（静的判定ではコードを基準とします。詳細は ../core/evidence.md を参照）
• 優先度の設定が妥当かを確認します（P0 は各項目をセルフチェックし、失敗するとコア機能が使用不能になるかを確認）。リスクレベルは ../core/risk-model.md に合わせます（Critical は必ず P0）

5. 修正とファイルへの保存

• ケースファイルを直接修正します：不足しているケースの追加（TC 番号を追加）、冗長なケースの削除、誤ったアサーションの修正、実行可能性に必要な要素の補足（導入セクション／制限時間／入口パス／具体的なデータ）。追加・書き換えたケースにも、../core/case-format.md の形式に関する厳格な制約を適用します（4段構成／協調型5段構成、TC 番号、本文にコードの内部実装を含めない）
• 修正後に Schema を再抽出し（フィールドとエスケープのルールは ../core/schema-extraction.md を参照）、../core/scripts/validate_schema.py で再検証して、合格したことを確認してから保存します
• ファイル末尾にレビュー記録を追加します：

## 审查记录（test-case-review {日期}）
- 基准：{人工标注 / 需求模型确认 / 自行提炼（未经确认）}
- 审查前：XX 条用例，XX 个模块
- 审查后：XX 条用例，XX 个模块
- 缺失（已补）：TC-xx…（{场景}）
- 冗余（已删）：TC-xx…
- 错误（已改）：TC-xx…（{问题→修正}）
- 高风险未覆盖：{风险点 + 建议用例，无代码证据则标注}
- 可执行性修复：{占位符/时限/入口 等 XX 处}

6. 納品

ユーザーに、修正後のファイルパス、レビュー記録の要約、基準の信頼性に関する説明（確認済みかどうか）、残っている提案（例：「コードパターンのレビューを追加することを推奨します」）を伝えます。

よくある間違い

誤り	結果	正しい方法
基準なしでカバレッジ率を評価する	自分で自分を評価することになり、数字に意味がありません	先にテスト可能なポイントの基準を作成し、信頼性を明示します
カバレッジだけを確認し、実行可能性を確認しない	カバレッジが100%でも、実行者が着手できません	カバレッジと実行可能性の両面からレビューします
問題を報告するだけでファイルを修正しない	レビューレポートとテストケースファイルが分離します	直接修正し、修正後に Schema を再抽出します
レビュー記録を独立したレポートファイルにする	成果物が分散し、後続の利用者が見つけられません	記録をケースファイルの末尾に追加します
テストケースの修正でプレースホルダーやコードの内部実装を持ち込む	新たな実行不能の問題を生み出します	修正時にも ../core/executability.md の基準を適用します
作成時のセルフレビューまで引き受ける	test-case-writing の役割と重複します	本 skill は事後の独立したレビューです