test-case-review

Test Case Review (test-case-review)

Answers "Are these test cases actually well tested" — a post-hoc, independent review (self-review during writing belongs to test-case-writing Phase 4).

Input: existing test case files (markmap + Schema, extract first if none), PRD / requirements model, code repository
Output (written to disk)：Directly revise the test case files(re-extract Schema after revision) + review record (appendix at end of file)
Review record content: missing / redundant / incorrect / high-risk uncovered, listed by TC number

When to Use

Review whether existing test case assets (legacy test cases, written by others) cover adequately and are executable
Review AI-produced test cases (dual track of coverage + executability)
Need a review conclusion independent of the author (self-review during writing cannot substitute)

When NOT to Use

Writing test cases from scratch → test-case-writing
Self-review during test case writing → test-case-writing Phase 4 (two-layer review 4A/4B)
Review step in the end-to-end pipeline → scheduled by qa this skill, but directly triggering this skill by a single user also applies
Regression scope selection after code changes → regression-testing

Workflow

1. Establish testable point baseline (denominator)

Coverage review needs a legitimate denominator, taken by priority:

Manually annotated testable point list (most authoritative when present)
Requirements model + testable point list jointly confirmed with the user (list before review starts, ask the user to fill gaps and confirm)
Only raw input sources → derive the testable point list from PRD/code yourself, **mark as "unconfirmed"** and ask the user to review upon delivery

Coverage without a denominator is grading your own homework — when the baseline is missing, state it truthfully and do not fabricate coverage.

2. Coverage review (at this point execute `../core/coverage.md`: full check of the core 7 dimensions item by item + cross-cutting executability)

Core seven dimensions item by item: functional main flow / input validation / reverse operations and lifecycle / state transitions / data consistency / implicit documentation requirements / code review findings (when code exists); extended dimensions (8–19) are selected by project type per coverage.md "Dimension Selection Quick Reference", no mechanical full check (execution intensity is routed by consumer, see its file header)
When re-checking the state transition dimension, load ../core/methods/state-machine.md: check test case coverage edge by edge per its "state set × event set × transition edge" list (at least one per edge + three mandatory categories: illegal transitions/concurrency races/reverse edges); when test cases are not organized by state machine, extract the state machine yourself in reverse and re-check, to prevent "looks like it's covered"
Second-order intersection（../core/testing-principles.md Section 3): write path × validation rules, failure × retry, identifier × duplication — the most common systematic gaps in existing test cases
Check and record point by point against the baseline: covered (TC number) / uncovered / covered but assertion wrong / redundant (multiple cases testing the same point) / invalid (not testing this requirement)

3. Executability review (at this point execute `../core/executability.md` all check items)

Go through the eight hard standards for each test case, focusing on hits:

Placeholder data ({xxx}, "some data"), fictional entry points, vague judgments ("function works normally"), async without time limit, over-strength assertions, unavailable preconditions without TODO, code internals in the body, missing the four-piece guide set

4. Correctness review (when PRD/code exists)

Whether the use case expected results are consistent with the PRD rules / code implementation (static adjudication: code prevails, see ../core/evidence.md）
Reasonableness of priority labeling (P0 self-check item by item: if it fails, is the core unusable?); risk level alignment ../core/risk-model.md(Critical must have P0)

5. Revision and Persistence

Revise directly in the use case file: add missing use cases (append TC numbers), delete redundancy, correct erroneous assertions, and add executability elements (guide section/time limit/entry path/specific data); for newly added and rewritten use cases,also enforce ../core/case-format.md format hard constraints(four-part/collaboration five-part, TC numbers, no code internals in the body)
After revision,re-extract the Schema(for fields and escaping rules, see ../core/schema-extraction.md), and use ../core/scripts/validate_schema.py to re-verify and pass before persisting
Append a review record at the end of the file:

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

6. Delivery

To the user: revised file path + review record summary + baseline credibility statement (whether confirmed) + remaining suggestions (e.g., "recommend adding a code pattern review").

Common Mistakes

Error	Consequence	Correct approach
Evaluating coverage directly without a baseline	Self-approving and self-revising, numbers are meaningless	First establish a testable point baseline and declare its credibility
Checking only coverage, not executability	100% coverage but the executor cannot start	Dual-track review of coverage + executability
Reporting problems only without revising the file	The review report and the use case file are two separate things	Revise directly + re-extract the Schema after revision
Writing the review record as a separate report file	Artifacts are scattered, downstream cannot find them	Append the record at the end of the use case file
Revised use cases introduce placeholders/code internals	Create new executability problems	Revisions also enforce `../core/executability.md` standards
Taking over the work of self-review during writing	Overlaps with the responsibilities of test-case-writing	This skill is post-hoc, independent review