What it does
Produces a performance test plan (29119-3 Test Plan, performance scope) with objectives tied to risks/SLAs, acceptance criteria carrying gates.performance values verbatim as pass/fail rules, an operational profile and workload model (transaction mix, volumes, concurrency, think-times, arrival pattern), the test types to run (load/stress/spike/soak/capacity), a non-prod system and data choice, a risk-to-workload traceability register, measurable entry/exit criteria, schedule, and metrics. Precedes scripting in perf-test.
When to use it
Before scripting load tests — to set objectives and SLAs and model the operational profile so perf-test enforces a tested requirement, not just a number.
Prerequisites
qa.config.yml (paths, gates.performance, risk_areas, environments, test_data, tooling.performance); plan-template.md for document structure.
Output
ISO/IEC/IEEE 29119-3 Test Plan (performance scope) -> docs/PERF-PLAN-<scope>.md (paths.docs_dir).
Mechanics
How it works
- Guard config and resolve scope (default risk_areas.critical)
- State objectives, one per question, tied to a risk or SLA
- Carry gates.performance SLAs verbatim as pass/fail rules
- Model the operational profile and workload (mix, concurrency, arrival)
- Select the performance test types and justify each by risk/objective
- Pick a non-prod environment and production-scale data; require APM
- Build the bidirectional risk-to-workload traceability register
- Set measurable entry/exit criteria, schedule, and metrics
Why it works
The theory behind it
CT-PT planning in the 29119-3 Test Plan shape, risk-driven (risk-based testing), targeting performance efficiency (ISO/IEC 25010); planning first turns 'a number' into a tested requirement.
CT-PT · ISO/IEC/IEEE 29119-3 (Test Plan) · CTFL v4.0 §5.2 · ISO/IEC 25010
Example
See it in use
> /qa:perf-plan "checkout"✓ Correct when It sets objectives/SLAs from gates.performance and a workload model (operational profile), feeding perf-test.