What it does
Reviews the test basis (requirements, user stories, acceptance criteria, OpenAPI spec) for testability, completeness, consistency and clarity, and returns a Review Report of findings; it writes no files and modifies no test object.
When to use it
Before writing tests for a story/spec, to find requirement defects while they are cheapest to fix (Principle 3).
Prerequisites
qa.config.yml (risk_areas drives subject selection); a test-basis item (story/spec/file) or empty to default to risk_areas.critical.
Output
ISO/IEC/IEEE 29119-3 Review Report (review findings), returned inline (no file written).
Mechanics
How it works
- Read config; establish subject and select review type by hint or risk tier
- Review the test basis for testability, completeness, consistency, correctness & clarity
- Review the API spec for gaps that weaken contract/API tests
- Route any source-code static analysis to /qa:static-analysis (out of scope here)
- Produce the Review Report as a findings table ordered by severity, with counts per type and severity
Why it works
The theory behind it
Static testing (CTFL v4.0 §3): reviewing the basis realizes Principle 3 (early testing) — a defect found in the requirement never becomes a defect in code. Formality scales from informal review to inspection. Principle 1: shows presence of defects, not absence.
CTFL v4.0 §3 · CTAL-TTA
Example
See it in use
> /qa:static-review "docs/stories/guest-checkout.md" walkthrough✓ Correct when It lists testability issues/ambiguities in the story (the test basis) before any tests are written, ordered by severity with counts per type.
Related commands
Used by