Role playbook · 04 / 05
Plan · Monitor · Decide
Mission: run the testing of a release — decide where to test deeply, track progress against the plan, take corrective action, and make the evidence-based ship/hold recommendation. The risk register drives everything.
ISTQB home turf: test planning, monitoring & control (§5) · risk-based testing (§5.2) · completion · CTAL-TM operational levelRelease kickoff
The risk assessment drives everything downstream: high-risk areas get test-design + exploratory depth; low-risk areas get standard test-cases. Brief the team from the register.
> /qa:risk-assessment R2.4 # 1 · score product & project risks (likelihood × impact) — drives everything > /qa:estimate "R2.4 scope" # 2 · effort estimation (metrics + expert based) > /qa:create-plan R2.4 "guest checkout, saved cards" # 3 · the Test Plan: scope, approach, entry/exit, schedule
Mid-release — weekly or per milestone
Monitoring is the measurement; control is the action. A status report that doesn't end in a decision is just a dashboard.
> /qa:status-report R2.4 # progress vs plan, defect trends, coverage, entry/exit status… # …and it ends with corrective ACTIONS: reassign, descope, add sessions > /qa:review-coverage # where is coverage thin vs the risk register? > /qa:regression "payment refactor" # a change landed → select & prioritize the regression set > /qa:flaky-hunt # pass-rate noise hides real signal — keep the suite trustworthy
Release endgame
> /qa:coverage-measure # 1 · final coverage vs requirements & risk > /qa:go-no-go R2.4 # 2 · the formal gate: all signals → ship/hold + conditions + sign-off > /qa:release-report R2.4 # 3 · Test Completion Report: exit criteria, residual risk, lessons learned
Severity is product impact; priority is fix urgency — keep them separate. A ship decision with three open low-severity defects and a residual-risk statement is ISTQB-correct. "Zero bugs" is not a thing.Principle 1 at the gate
Where your work goes
/qa:quality-report./qa:go-no-go decision.Cheat sheet
| You need to… | Run |
|---|---|
| Decide where to test deeply | /qa:risk-assessment <release> |
| Write the release test plan | /qa:create-plan <release> <features> |
| Report progress + take action | /qa:status-report <release> |
| Pick the regression set for a change | /qa:regression <change> |
| Make the ship / hold call | /qa:go-no-go <release> → /qa:release-report <release> |
Switch hats
You can be all five — switch playbooks as the day demands. See how the roles interlock on the release-lifecycle timeline.