QA Toolkit — A field manual for ISTQB-aligned testing

One toolkit. Every testing role.

Sixty-four /qa:* slash commands turn Claude Code into a full QA department — aligned with ISTQB CTFL v4.0 and the Advanced & Specialist syllabi, documented to ISO/IEC/IEEE 29119-3. Install once as a plugin; the only file that changes between projects is a single qa.config.yml.

v3.10.0 59 commands MIT license ISTQB-aligned Playwright · K6 · Pact · axe

your-project — claude

> /qa:qa-init# interview → qa.config.yml> /qa:create-strategy# → docs/qa/TEST-STRATEGY.md> /qa:scaffold# → Playwright+TS · K6 · Pact · CI> /qa:implement "guest checkout"# → E2E + API + contract tests

Three ideas, one config file.

The toolkit lives in one GitHub repo and behaves identically in every project you point it at. What varies per project fits in a single YAML file.

Install once, identical everywhere

The toolkit ships as a Claude Code plugin: 64 commands, auto-loading skills, and ISO-29119 document templates. Improve the toolkit in one place and every project gets the upgrade with /plugin marketplace update.

One file differs per project

qa.config.yml captures your stack, tooling toggles, CI platform, quality-gate thresholds, risk areas, environments, and team. Every command reads it — you never re-specify your stack or SLAs.

Every command is an ISTQB activity

Each command implements a test-process activity — planning, monitoring & control, analysis, design, implementation, execution, completion — and emits proper testware: test plans, case specs, defect reports, completion reports.

From zero to a running suite.

Two plugin commands per machine, one init per project. Everything after that reads the config.

Add the marketplace once per machine

claude

> /plugin marketplace add toronto-nigma/qa-toolkit

Install the plugin

claude

> /plugin install qa@qa-toolkit

Initialize your project once per repo

your-project — claude

$ cd your-project> /qa:qa-init# interactive interview → ./qa.config.yml

The five role playbooks

Pick your role. Run the loop.

Each playbook gives a role's mission and its command loop, so one person can carry the entire role through the agent. You can be all five — just switch playbooks as the day demands. The roles hand work to each other at well-defined points; the lifecycle timeline below shows the whole picture.

Manual Tester

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-TA Open the Manual Tester page →

Core loop — per user story

static-review→acceptance→test-cases→test-data→(execute)→exploratory→triage

When the feature is bigger

test-design complex rules · combinatorial pairwise · mbt stateful flows · review-coverage gaps

Hands off to: Automation Tester — stable manual cases become /qa:automate candidates scored by ROI — and Test Leader, whose status-report reads your execution results and defects.

Automation Tester

Build · Run · Maintain

Mission: build and maintain a fast, deterministic, maintainable automation suite at the right pyramid levels — and keep CI green honestly, never masking real defects. Maintenance is half the job.

ISTQB home turf: CT-TAE (gTAA architecture) · test implementation & execution (§1.4) · maintainability · CTAL-TTA

"A genuine product defect goes to triage and the test keeps asserting correct behavior. A green build you can't trust is worse than a red one." The honesty rule

Open the Automation Tester page →

Setup — once per project

automation-strategy→scaffold→test-env

Core loop — per feature

automate→implement→api-automate / scan-ui / web-automate

Maintenance loop — keep CI honest

fix-jenkins · fix-ci · flaky-hunt · self-heal — real defects → triage

Receives from: Manual Tester (case CSVs) and Test Leader (risk priorities). Hands off to: everyone — your suite is the safety net regression, status-report, and go-no-go read from.

Performance Tester

Plan · Load · Analyze

Mission: prove the system meets its performance SLAs under realistic and extreme load — and catch degradation before users do. Thresholds live in qa.config.yml and run as CI gates.

ISTQB home turf: CT-PT — workload modeling · load / stress / spike / soak · threshold-based gates

"Never script before planning. perf-test without a perf-plan tests a number, not a requirement." Performance rule №1

Open the Performance Tester page →

Core loop — per release or risk area

perf-plan→perf-test load → stress → spike → soak→dynamic-analysis

Beyond load

nonfunctional reliability · shift-right prod monitoring · results feed go-no-go

Hands off to: Test Leader / Manager — threshold pass-fail and capacity headroom feed go-no-go and quality-report.

Test Leader

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 Open the Test Leader page →

Release kickoff

risk-assessment→estimate→create-plan

Weekly — monitoring & control

status-report · review-coverage · regression · flaky-hunt

Release endgame

coverage-measure→go-no-go→release-report

Receives from: everyone — execution results, defects, perf thresholds, coverage. Hands off to: Test Manager (reports roll up into quality-report) and the org (the go-no-go decision). Remember: severity ≠ priority.

Test Manager

Policy · People · Process

Mission: own the test organization — policy, strategy, people, budget, process maturity, and the quality story told to executives. You work across releases, not inside one.

ISTQB home turf: CTAL-TM strategic · Expert Test Management · Improving the Test Process (TMMi) Open the Test Manager page →

Foundations — once, then yearly review

test-policy→create-strategy→automation-strategy→tool-select

Management rhythm

quality-report monthly · team-plan · cost-of-quality quarterly · process-improvement half-yearly · audit-prep before audits

Receives from: Test Leader (per-release reports) and Automation Tester (automation-audit health scores). Hands off to: the organization — policy, strategy, budget, and the quality narrative.

All five roles, one timeline.

How the playbooks interlock across one release — the same role colors as above, end to end. Full map in WORKFLOWS.md.

M Manual A Automation P Performance L Leader TM Manager

Plan

release kickoff

TM
test-policy / create-strategy — standing, reviewed yearly
L
risk-assessment→estimate→create-plan <release>
A
automation-strategy→scaffold — once per project
P
perf-plan <high-risk area>

Build

per story, repeating all sprint

M
static-review→acceptance→test-cases→execute→exploratory
A
automate→implement→api-automate / web-automate / test-data
MA
triage <any real defect>
A
fix-jenkins / fix-ci / flaky-hunt / self-heal — keep CI honest

Stabilize

release hardening

L
status-report weekly→control actions
L
regression <changes> · review-coverage
P
perf-test load / stress / spike vs release candidate
P
security-scan · a11y-audit — non-functional sweep

Ship

the gate

LTM
coverage-measure→go-no-go — Leader gates, Manager signs off
L
release-report — residual risk, lessons learned

Between releases

the long game

TM
quality-report · team-plan · cost-of-quality · process-improvement
A
automation-audit · static-analysis — quarterly health check
P
perf-test soak + dynamic-analysis — quarterly

All 64, grouped by activity.

A command for every ISTQB test-process activity. Click any command for its dedicated page — what it does, how it works, the theory behind it, and a worked example. See them all on the command catalog; the Command Guide has the full how-to and worked examples cover every command.

8 + 5 + 10 + 6 + 6 + 6 + 8 + 5 + 4 + 4 + 2 = 64 commands — one for every ISTQB activity. Browse all 64 as pages →