What it does
One pipeline: filter unsuitable items, score priority (value) and complexity (cost), select candidates on a 5x5 ROI matrix, design the automated cases, produce a phased plan, and implement the Phase-1 candidates. Automation is treated as an ROI investment decision, never 'automate everything.'
When to use it
Deciding what to automate, or converting manual test cases into automated tests.
Prerequisites
qa.config.yml (run /qa:qa-init first); manual cases / requirement / feature input; honors paths.*, tooling.*, risk_areas, process.sprint_length_weeks.
Output
Automation Plan -> paths.docs_dir/AUTOMATION-PLAN-<item>.md (Test Plan) plus implemented Phase-1 scripts under paths.tests_dir (Test Procedure Specification).
Mechanics
How it works
- Guard config and resolve the input (manual cases, requirement, or feature -> its TEST-CASES doc)
- Suitability filter: drop items unsuitable for automation and keep them manual with a reason
- Score PRIORITY 1-5 (P1..P5), risk-led
- Score COMPLEXITY 1-5 (C1..C5)
- Select candidates on the 5x5 priority x complexity ROI matrix and assign the lowest effective test level
- Design the automated cases preserving bidirectional traceability
- Plan the phased rollout mapped to sprints; implement the Phase-1 (P1) candidates and run them
Why it works
The theory behind it
CT-TAE + risk-based prioritization (CTFL §5.2) + implementation/execution (§1.4). Automating by ROI rather than wholesale is the economic core of CT-TAE; the pyramid pushes work to the lowest effective level.
CT-TAE · CTFL v4.0 §5.2 · §1.4
Example
See it in use
> /qa:automate "docs/manual/checkout-cases.csv"✓ Correct when It scores each case by ROI/complexity and automates the high-value ones first.
Related commands
Used by