Summary
Quality assurance (QA) is the work of reducing the chance that a game ships with unacceptable defects, broken flows, or platform compliance failures. Bug triage is the decision process that turns a list of defects into a prioritised set of fix obligations — deciding what must be resolved before launch, what can wait for a patch, and what the team will knowingly ship with.
The key distinction, made explicit by Keith (Agile Game Development): most of what teams call QA is really QC (quality control) — reactive defect finding after problems already exist. True QA is broader and earlier: it includes the practices that reduce the likelihood and cost of defects in the first place.
(Keith, Agile Game Development, see source-agile-game-development; IGDA, Best Practices in QA and Testing, see source-igda-qa-and-contracts)
QA vs QC
The distinction matters because it shapes when and how the team invests in quality work.
| Term | Definition | When it happens |
|---|---|---|
| Quality Assurance (QA) | Proactive work to prevent defects and ensure processes produce good outcomes | Throughout development — in planning, sprint reviews, design critiques, code reviews |
| Quality Control (QC) | Reactive work to detect and report defects after they exist | At the end of a feature cycle, during test phases, release candidates |
Most game teams practice primarily QC and call it QA. The practical implication: a team that only tests at the end of a sprint has no QA — it has QC with a lagged feedback loop. By the time the bug is found, the code that caused it may be two sprints old and difficult to change.
QA in practice includes:
- Agreeing on a definition-of-done before work starts (not after)
- Reviewing design specifications for testability before implementation
- Code review (catching defect-prone patterns before they are tested)
- Automated tests where feasible
- Sprint Reviews that treat the playable build as an acceptance test
“Most QA is just QC.” — Keith, Agile Game Development, Ch. 15
Bug classification: severity and priority
Every defect requires two independent judgements. Conflating them produces triage errors.
Severity
Severity describes how bad the defect is when it occurs — its impact on the player experience.
| Severity | Description | Examples |
|---|---|---|
| Critical | Game crash, data loss, unrecoverable failure | Crash on startup, save file corruption, soft-lock with no escape |
| High | Core gameplay broken or significantly degraded | Combat system skippable, progression permanently blocked |
| Medium | Feature degraded but workaround exists | Incorrect game state on retry, visual glitch during cutscene |
| Low | Minor cosmetic or convenience issue | Text alignment off, tooltip spelling error, audio slightly desynchronised |
Priority
Priority describes how urgently the team needs to act — accounting for proximity to release, likelihood of the defect being encountered, and cost of fixing.
| Priority | Description |
|---|---|
| P1 | Fix immediately; blocks further testing or is a guaranteed release blocker |
| P2 | Fix this sprint; significantly affects quality of current build |
| P3 | Fix before release; does not block current work |
| P4 | Fix post-launch or accept as known issue |
The severity–priority matrix
Severity and priority can diverge:
| Combination | Example | Triage outcome |
|---|---|---|
| Critical severity + P1 priority | Crash on main menu | Fix immediately |
| Critical severity + P3 priority | Crash in a debug-only test scene never shown to players | Fix before release, low urgency now |
| Low severity + P1 priority | Game logo wrong in screenshots; press review copies about to be distributed | Fix immediately despite cosmetic nature |
| High severity + P4 priority | Major bug in a feature cut from this release | Accept and mark deferred |
The matrix prevents two failure modes: (1) treating all critical bugs as equally urgent regardless of likelihood, and (2) dismissing cosmetic bugs that happen to matter for reasons outside the game itself.
Test types
Functional testing
Verifying that specific features work according to their specification. Each acceptance criterion on a user story is a functional test case: “Given this input, the output is X.”
A functional test is only as good as its acceptance criteria — if the criteria are vague, the test cannot determine pass or fail.
Regression testing
Testing that a fix or new feature has not broken something that was previously working. Regression is the most commonly skipped test type under schedule pressure, and the most commonly regretted omission.
Rule: every significant change — bug fix, optimisation, or new feature — should be followed by regression testing of the areas most likely to have been affected. This is especially important for:
- Physics and collision systems (changes propagate unpredictably)
- Save/load systems (data format changes can corrupt existing saves)
- Input remapping (affects all player interactions simultaneously)
Smoke testing
A lightweight first-pass test of the most critical paths: can the game start, can the main loop be reached, can the game be saved and loaded? A smoke test is run immediately after a build is produced. If it fails, the build is not distributed to the broader team.
The term comes from electronics: powering on a circuit board to see if anything catches fire before detailed testing begins.
Exploratory testing
Unscripted testing where the tester actively attempts to break the game — following unexpected paths, combining mechanics in unusual ways, deliberately exceeding intended ranges. Exploratory testing finds bugs that scripted test plans cannot, because scripts only test known scenarios.
Experienced QA testers are more valuable in exploratory sessions than in scripted ones; scripted testing can be done by anyone following a checklist.
Release blockers
A release blocker is any defect that must be fixed before the build can ship. The team defines what counts as a blocker before the final stretch — not during a late-night panic.
A sensible release blocker policy:
| Category | Blocker? | Rationale |
|---|---|---|
| Game crash on any main-path player action | Yes | Unacceptable player experience |
| Permanent progression block with no workaround | Yes | Players cannot complete the game |
| Data loss (save file corruption) | Yes | Destroys player investment |
| Platform certification failure | Yes | Legal and commercial requirement for console/storefront release |
| Legal/IP violation (unlicensed content) | Yes | Legal liability |
| Severe accessibility failure (missing required text alternatives) | Depends on platform | Some platforms require minimum accessibility standards |
| Moderate visual glitch on non-critical path | No | Known issue; acceptable risk |
| Balance problem that does not block play | No | Day-one patch candidate |
Platform certification adds a layer of non-negotiable blockers. Microsoft (Xbox), Sony (PlayStation), Apple (App Store), Google (Play Store), and Valve (Steam) all have technical requirements that, if violated, result in submission rejection. Xbox’s certification documentation explicitly includes system integration, UI behaviour, and accessibility requirements — not just crash rates.
(Microsoft, Xbox Requirements, see source-xbox-accessibility-and-certification)
Late-breaking fixes and change risk
Every fix introduced close to a release candidate is a risk: a change that resolves one bug may introduce two others. The discipline of late-stage fix justification asks: does fixing this bug reduce total shipping risk, or does it increase it?
Rules of thumb:
- Fix critical defects at any stage — the risk of shipping with a crash is worse than the risk of the fix
- Fix high-severity bugs only if the fix is low-risk (isolated code change, easily regression-tested)
- Do not fix medium or low bugs inside the final release candidate window — log them for the day-one patch instead
QA in Agile sprints
In a Scrum process, QA is not a separate phase — it is embedded in every sprint. The definition-of-done includes quality criteria; testing happens within the sprint rather than after it.
QA activities by sprint phase:
| Sprint phase | QA activity |
|---|---|
| Sprint Planning | Agree on acceptance criteria per story; identify test cases before work starts |
| Development | Author writes functional tests alongside code; component testing as work proceeds |
| Near-sprint end | Integration testing; regression on changed areas; playtest build |
| Sprint Review | Stakeholders test the build; feedback becomes input to next sprint backlog |
| Retrospective | Identify recurring defect patterns; improve process to prevent recurrence |
The Sprint Review is particularly valuable as a lightweight acceptance test: if the Product Owner cannot accept a story as “done” after a Review, it was not done.
Keith notes that studios that separate testing into a dedicated post-sprint phase reintroduce the waterfall problem: bugs found after the sprint are expensive to fix because the team has already moved on.
(Keith, Agile Game Development, see source-agile-game-development)
In practice: QA for small teams
Small indie teams and student projects typically have no dedicated QA staff — testing is everyone’s responsibility. The following minimum practices are achievable without a QA team:
- Write acceptance criteria before implementation. If you cannot write a test for the feature before building it, the feature is not clearly enough defined.
- Smoke-test every build before sharing it. Ten minutes of basic path testing prevents wasted review sessions on broken builds.
- Separate bugs from feature requests. A bug tracker entry should be one reproducible defect with clear steps, expected behaviour, and actual behaviour. Feature requests go on the product backlog.
- Classify by severity and priority. Use the two-axis system even informally — it stops the team from treating every bug as equally urgent.
- Agree on release-blocker criteria before the final week. “What would stop us from shipping?” is a question to answer in sprint planning, not at 2am the night before launch.
- Regression-test after every significant fix. Especially: save systems, physics, and anything that affects all players simultaneously.
- Playtest as QA. Structured playtesting (see playtesting) is quality assurance — it detects design failures that technical testing cannot.
For student projects: one person rotating the QA role per sprint, using a shared bug tracker (GitHub Issues, Trello, or a spreadsheet), is sufficient for a team of three to five people.
Implications
- QA belongs in production planning even when a team has no dedicated QA role.
- The decision of what counts as a release blocker should be made collectively and explicitly — not improvised under pressure.
- Triage quality determines whether the team ships a good-enough product or spends the final week firefighting.
- Regression discipline is inversely correlated with crunch: teams that regression-test regularly spend less time fixing surprise breakages near launch.
Open questions
- Which QA practices offer the best return for small university teams with one-semester timescales?
- How should accessibility bugs be triaged relative to crash bugs when both are present? Some argue any accessibility failure is as critical as a crash for the affected players.
- Automated testing in Unity (Unity Test Framework, NUnit) can catch regressions efficiently — but the setup cost is non-trivial. At what team size or project scale does automated testing become worthwhile?
Related
definition-of-done | playtesting | sprints | build-and-release-management | accessibility-and-localisation | post-launch-and-live-ops | team-dynamics-and-roles | source-control | overview-full-game-development-pipeline | source-igda-qa-and-contracts | source-agile-game-development | source-xbox-accessibility-and-certification