Test planning & management 13
/qa:qa-initInterview you and generate the per-project qa.config.yml — the single file every other /qa command reads.open →
/qa:test-policyAuthor the Organizational Test Policy — the highest-level statement of why the org tests and what quality means, above any single project.open →
/qa:create-strategyGenerate or refresh the program-wide Test Strategy from qa.config.yml — levels, types, techniques, automation, environments, entry/exit criteria.open →
/qa:create-planBuild a release- or sprint-scoped Test Plan from the config plus a release name and feature list — scope, approach, entry/exit criteria, schedule, risks.open →
/qa:risk-assessmentScore product and project risks (likelihood × impact), assign a tier, and derive the per-tier test response — risk-based testing.open →
/qa:estimateEstimate testing effort for a release, feature, or backlog using both metrics-based and expert-based ISTQB techniques, expressed as a range.open →
/qa:tool-selectEvaluate and select a testing tool with the ISTQB process — category, weighted criteria matrix, benefits/risks, pilot — as an ROI decision record.open →
/qa:process-improvementAssess test-process maturity and recommend prioritized improvements using an ISTQB 'Improving the Test Process' / IDEAL lens — advisory only.open →
/qa:quality-reportProduce a cross-release quality KPI dashboard / executive report — trends for escaped defects, coverage, pass rate, MTTR, automation %, flaky rate.open →
/qa:team-planPlan QA team capacity and skills — staffing vs backlog, a skills matrix, gaps, key-person risk, and a training/onboarding plan.open →
/qa:go-no-goRun a formal release go/no-go review — consolidate every quality signal into a documented ship/hold decision with conditions, residual risk, and sign-off.open →
/qa:cost-of-qualityAnalyze Cost of Quality and automation ROI — prevention/appraisal/failure costs, cost of poor quality, and payback — to justify the QA budget.open →
/qa:audit-prepAssemble an audit-readiness evidence pack — documentation completeness, traceability sample-checks, standards conformance, and a severity-ordered gap list.open →
Static testing, analysis & design 10
/qa:static-reviewReview a story, spec or API spec for testability and defects before any tests are written — shift-left review findings; source-code analysis is routed to static-analysis.open →
/qa:test-casesDerive concrete test cases from a requirement, story, endpoint or file using ISTQB design techniques — a Test Case Specification with negative and boundary coverage, not just happy path.open →
/qa:test-designDerive test conditions then cases across the full technique set (EP, BVA, decision table, state transition, ATDD) for a feature — broader design context than single-item test-cases.open →
/qa:combinatorialCover a many-parameter feature with pairwise, classification-tree or orthogonal-array cases — strong interaction coverage with far fewer tests than exhaustive.open →
/qa:acceptanceAuthor agreed, testable acceptance criteria and Given/When/Then scenarios collaboratively before development — the story's definition of done, with each criterion traced to a scenario.open →
/qa:mbtModel a stateful flow as a state machine and derive cases to a stated coverage criterion (all-states / all-transitions / 0-switch) — provable completeness instead of ad-hoc cases.open →
/qa:exploratoryPlan time-boxed, risk-driven charters with heuristics and oracles plus a reusable session sheet — experience-based testing that complements, never replaces, scripted coverage.open →
/qa:static-analysisAnalyze source without running it — complexity, control-/data-flow, coding-standard and maintainability metrics — and report defect-prone units early; writes only the report, never the code.open →
/qa:automation-auditScore an inherited automation suite end-to-end — gTAA architecture, SOLID & clean code, test-design quality, anti-patterns, pyramid, CI — into a maturity scorecard with prioritized, routed fixes. Read-only.open →
/qa:review-coverageAudit coverage gaps against strategy and risk, verify the bidirectional traceability chain in both directions, and rank the highest-value missing tests. Read-only.open →
Test implementation 6
/qa:scaffoldBuild the gTAA framework, fixtures, config, and CI pipeline from qa.config.yml.open →
/qa:automateScore ROI, pick automation candidates, design cases, plan, and implement the top ones.open →
/qa:implementTurn cases into tests at the right pyramid level (E2E/API/component/contract) and run them.open →
/qa:add-testFrom a plain-English description, pick the ISTQB technique, then implement and run one test.open →
/qa:test-dataTyped factories, builders, fixtures, and seeding/cleanup helpers, synthetic-only.open →
/qa:test-envDefine, provision, and gate a reproducible test environment from qa.config.yml.open →
Test automation by surface 6
/qa:automation-strategyDefine the long-lived automation architecture: objectives, level split, tool fit, CI, maintainability, metrics, ROI.open →
/qa:api-automateBuild or extend automated REST tests from the spec: schema, CRUD, auth/role matrix, negative and boundary, data-driven.open →
/qa:scan-uiDeep-dive a web UI to extract stable locators and actions into page objects, then generate cases covering every element and flow.open →
/qa:web-automateBuild or extend system-level E2E tests for critical user journeys: POM, per-role auth state, cross-browser, gated a11y/visual hooks.open →
/qa:mobile-automateAutomate iOS/Android app flows via Appium or a device farm — gestures, lifecycle, network, platform differences — with a device-matrix table.open →
/qa:perf-planPlan performance testing before scripting: objectives, SLAs, operational profile, workload model, test types, entry/exit — risk-driven.open →
Test execution — functional & non-functional 14
/qa:perf-testScript (and optionally run) a K6 load/stress/spike/soak test with pass/fail thresholds from config gates.open →
/qa:a11y-auditScaffold or run automated accessibility (axe) checks against the configured WCAG target, then write the execution log.open →
/qa:usability-testEvaluate UX with ISTQB usability methods, heuristics, and ISO/IEC 25010 sub-characteristics — distinct from accessibility.open →
/qa:nonfunctionalDesign and (where automatable) run reliability/compatibility/portability/maintainability tests against measurable ISO/IEC 25010 criteria.open →
/qa:security-scanWire or run the automated security baseline — SAST, SCA, DAST, secrets — gated by config toggles, OWASP-aligned.open →
/qa:contract-syncGenerate/verify consumer and provider Pact contracts and run a can-i-deploy gate across the web/API boundary.open →
/qa:mobile-testTest responsive mobile-web behavior using CT-MAT concerns — viewports, touch, network, device matrix.open →
/qa:ai-testTest AI/ML components using CT-AI methods — data quality, model metrics, bias/fairness, robustness, explainability, drift.open →
/qa:regressionSelect, prioritize, and optimize the regression set via impact analysis; keep the suite lean.open →
/qa:ciPull the whole failing build (any CI), bucket every failure, fix the fixable causes, harden to green ×3, and escalate real defects.open →
/qa:fix-ciDiagnose one failing CI pipeline or test run, classify the root cause, and apply a safe fix without masking product defects.open →
/qa:fix-jenkinsPull the latest Jenkins build's failed cases, fix each by root cause, and re-run only those locally until green.open →
/qa:flaky-huntFind flaky/non-deterministic tests, quarantine against an SLA, fix the root cause (not blind retries), and report.open →
/qa:self-healRepair broken locators after UI changes, prune/refactor obsolete tests, and re-run to confirm — heals how we locate, never what we verify.open →
Monitoring, control & completion 4
/qa:status-reportMid-release monitoring metrics plus control actions vs the plan.open →
/qa:coverage-measureMeasure structural, requirements and risk coverage, then name the holes.open →
/qa:triageClassify a failure, separate severity from priority, write a proper defect report.open →
/qa:release-reportEvaluate every gate, state residual risk, give a deterministic Ship/Hold call.open →
Version control & PR quality 4
/qa:review-prReview a PR from a testing view — coverage of the diff, regression risk, testware quality, defects — then a gate-based merge call.open →
/qa:commitVerify the staged change first (affected tests, lint, static review as confirmation testing), then commit with a Conventional Commits message that traces to the requirement or defect.open →
/qa:open-prRaise a PR whose body is real QA evidence — what changed, what was tested, coverage delta, the regression set run, residual risk, and linked defects.open →
/qa:merge-gateEvaluate a PR against the project's gates — CI status, pass rate, coverage, severity blockers, security/a11y/perf — into a documented merge / hold decision. A change-scoped go/no-go that never auto-merges.open →