What it does
Takes a Three Amigos view to surface ambiguities, writes specific/measurable/verifiable acceptance criteria (the test conditions), expresses them as Gherkin scenarios (the test cases), classifies each for automation and acceptance-testing form, and keeps criterion->scenario traceability.
When to use it
Turning a user story into agreed, testable acceptance tests before development (shift-left).
Prerequisites
qa.config.yml (paths.docs_dir, risk_areas, enabled tooling.* for execution level, stack.api_spec_path where a criterion maps to an endpoint); a story, or empty to default to the first risk_areas.critical area.
Output
ISO/IEC/IEEE 29119-3 Test Case Specification (acceptance level) -> docs/ACCEPTANCE-<story>.md.
Mechanics
How it works
- Three Amigos perspective: surface assumptions/ambiguities, route basis defects to /qa:static-review
- Write acceptance criteria (test conditions) that are specific, measurable, verifiable, each risk-tagged
- Express each criterion as Given/When/Then scenarios (one observable outcome each), using Scenario Outline for data sets
- Classify each scenario: test level, CT-AcT acceptance form, priority
- Maintain criterion->scenario traceability; output criteria table, scenario spec and counted coverage summary
Why it works
The theory behind it
ATDD is the CTFL v4.0 §4.5 collaboration-based design technique; the acceptance-testing forms (UAT, operational, contractual/regulatory, alpha/beta) belong to CT-AcT and are kept distinct from §4.5. Agreeing tests before development is shift-left (Principle 3) and defends against the absence-of-errors fallacy (Principle 7).
CTFL v4.0 §4.5 (ATDD) · §2.2 (acceptance level) · CT-AcT (forms)
Example
See it in use
> /qa:acceptance "Guest checkout with a saved card"✓ Correct when It produces Given/When/Then scenarios agreed as the acceptance criteria (ATDD), each criterion traced to a scenario, with counts in the coverage summary.
Related commands
Used by