Role playbook · 01 / 05
Static · Design · Exploration
Mission: find defects early and validate the product against real user needs — through static review, designed test cases, and skilled exploration. Shift-left is where you're cheapest to the project: review every story before dev finishes.
ISTQB home turf: static testing (§3) · test analysis & design (§4) · defect management (§5.5) · experience-based techniques · CTAL-TAThe core loop
Run this loop on every story. The first two steps happen before development completes — that is the whole point of shift-left.
> /qa:static-review "US-123 guest checkout" # 1 · review the story before dev finishes — find requirement defects now > /qa:acceptance "US-123" # 2 · agree testable acceptance criteria (ATDD / Gherkin) with the team > /qa:test-cases "US-123" # 3 · derive cases with EP, BVA, decision tables (+ CSV export) > /qa:test-data order # 4 · get the data you need to execute … execute the scripted cases against the test environment … > /qa:exploratory "guest checkout" # 5 · session-based exploration around the scripts (charter, timebox) > /qa:triage "checkout accepts expired card" # 6 · every real defect → ISTQB report (severity vs priority)
Scale the technique to the risk
| Situation | Reach for |
|---|---|
| Complex business rules / states | /qa:test-design <feature> — full conditions + cases, decision tables, state transitions |
| Many parameters combine (filters, options, configs) | /qa:combinatorial <feature> — pairwise instead of exhaustive |
| A stateful flow (cart, order lifecycle, auth) | /qa:mbt <flow> — model it, derive cases by coverage |
| "Did we miss anything?" | /qa:review-coverage <area> — gap analysis vs risk |
| Unsure which technique applies | /qa:istqb-coach "when do I use decision tables?" |
Your cadence
static-review→acceptance — shift-left; cheapest defects to catch
test-cases→test-data
exploratory — one session on the riskiest angle
triage — never report a bug informally
hand stable cases → automate your-cases.csv (scored by ROI)
Review the story before dev finishes — that is the moment a defect costs the project the least.The shift-left rule
Where your work goes
/qa:automate candidates, scored by ROI./qa:status-report.Cheat sheet
| You need to… | Run |
|---|---|
| Start in a brand-new repo | /qa:qa-init → /qa:scaffold |
| Review a story before dev finishes | /qa:static-review <story> |
| Agree acceptance criteria | /qa:acceptance <story> |
| Turn a requirement into cases | /qa:test-cases <req> |
| Explore a risky area | /qa:exploratory <area> |
| Report a bug properly | /qa:triage "<bug>" |
| Learn / check an ISTQB concept | /qa:istqb-coach <topic> |
Switch hats
You can be all five — switch playbooks as the day demands. See how the roles interlock on the release-lifecycle timeline.