What it does
Produces the program-level Test Automation Strategy for the product (long-lived, automation-specific, above any single feature or release): objectives and business case, scope, the four gTAA layers, automation approaches, pyramid level distribution, tooling fit, CI/CD integration, maintainability strategy, metrics, and risks. Treats automation as an investment/ROI decision, never 'automate everything.'
When to use it
When you need to set or review the overall automation approach above any single feature or release; once per project, or as a refactor target for an inherited suite.
Prerequisites
qa.config.yml (paths, tooling toggles, gates, risk_areas); discovery scan of existing framework/CI; automation-strategy-template.md.
Output
Test Automation Strategy work product (gTAA per CT-TAE; ISO/IEC/IEEE 29119-3 alignment) -> docs/AUTOMATION-STRATEGY.md (paths.docs_dir).
Mechanics
How it works
- Guard config and resolve scope argument (default focus risk_areas.critical)
- State objectives and business case tied to measurable success criteria
- Set scope: levels and surfaces in vs out, per enabled tooling
- Define the four gTAA layers (generation, definition, execution, adaptation)
- Choose and justify automation approaches (data/keyword/BDD/model)
- Set the pyramid level distribution and map each level to tooling
- Confirm tooling fit and CI/CD integration with gate rules
- Specify maintainability strategy, metrics with thresholds, and risks
Why it works
The theory behind it
Generic Test Automation Architecture (gTAA) plus program-level automation strategy (CT-TAE); ROI/investment framing; SUT decoupled from tests via the adaptation layer.
CT-TAE (gTAA) · Test Automation Strategy (Specialist) · ISO/IEC/IEEE 29119-3
Example
See it in use
> /qa:automation-strategy✓ Correct when Defines the gTAA 4 layers, the pyramid split, and maintainability/metrics — program-level, not per-feature.