Game QA

This skill owns the QA pass taxonomy and the evidence card used by QA-oriented compatibility entries such as test-matrix. It does not own gameplay success criteria (gameplay-validation), performance budgets (performance-budget), or vendor certification requirements.

Pass taxonomy

A project may add passes, but each pass gets a unique name and acceptance contract rather than redefining another pass silently.

Evidence card

Every executed row records at least:

case/pass id
build id + commit/version
platform/target + device/input
configuration/difficulty + QA/debug state
result: pass | fail | blocked | not-run
artifact/evidence reference
known deviations + untested remainder

pass means the stated row ran and met its criteria. A unit/static check, screenshot, capture, or telemetry counter cannot be substituted for a different evidence class.

Rules

1. Separate product defect, expected design, player strategy, harness failure, environment/setup failure and tool failure.
2. A fix gets a stable regression case ID when recurrence would matter.
3. Combination coverage is selected from real interaction risk, not an assertion that every pair must be tested.
4. gameplay-validation owns human/agent completion claims; automation may support them but does not silently convert functional evidence into playtest evidence.
5. cert-handoff provides lifecycle/cert-relevant event contracts; platform/vendor requirement sources remain external and versioned.
6. Release decisions consume these cards through ship-checklist; QA itself does not claim “ship” because one pass is green.

Accept

A reviewer can identify the exact build, target, pass, configuration, result, evidence and untested remainder. Re-running the same case against another build creates another evidence record rather than overwriting history.