What it does
Produces the long-lived, project-general test approach: it maps test levels and types to your configured stack, carries gates thresholds verbatim into entry/exit criteria, derives risk tiers from risk_areas, and omits sections for any disabled tooling. It tailors the seven test-process activities to the project's agile cadence.
When to use it
When you need the overall QA approach for the product. Sits between the Test Policy (above) and the per-release Test Plan (below).
Prerequisites
qa.config.yml (run /qa:qa-init first) — paths, every tooling toggle, ci.platform/browsers, gates, risk_areas, team, test_data, environments, process.
Output
ISO/IEC/IEEE 29119-3 Organizational Test Strategy -> <paths.docs_dir>/TEST-STRATEGY.md.
Mechanics
How it works
- Config guard: stop and route to /qa:qa-init if missing
- Parse config as single source of truth (paths, tooling, stack, ci, gates, risk_areas, process)
- Load the strategy template and follow its section order
- Include a section per enabled tooling.* toggle; omit and list disabled ones as out of scope
- Carry gates thresholds verbatim into entry/exit-criteria and metrics
- Derive risk tiers and test depth from risk_areas (risk = likelihood × impact)
- Write TEST-STRATEGY.md, project-general and long-lived
Why it works
The theory behind it
Test planning at program scope (CTFL §5.1; CTAL-TM; agile mapping per CTFL-AT). The ISO/IEC/IEEE 29119-3 Organizational Test Strategy is product/org-wide and long-lived, distinct from a release Test Plan; building it from config enforces context-dependence (Principle 6) and keeps the test basis -> result traceability chain whole.
CTFL v4.0 §5.1 · CTAL-TM · CTFL-AT
Example
See it in use
> /qa:create-strategy✓ Correct when The level distribution, tooling, and CI match qa.config.yml, disabled tools are listed out of scope, and it follows the ISO 29119-3 strategy structure.
Used by