⚠️ This is a condensed version of the article.
👉 Read the full, updated version (canonical version):
This DEV version summarises the workflow. The full version includes complete structure, deeper examples, and full QA context.
TL;DR
- What it is: a game QA functional testing workflow for timeboxed solo passes
- Backing project: Battletoads (PC Game Pass), one-week pass
- Approach: validate start-to-control and Pause/Resume first, then expand where risk appears
- Outputs: pass/fail results, reproducible bug reports, and short evidence clips
Game QA functional testing workflow used during a one-week Battletoads (PC) pass.
What functional testing is (in game QA)
Functional testing answers one question:
Does the game do what it claims to do, end-to-end?
I validate core flows, confirm expected behaviour, and write issues so a developer can reproduce them without guessing.
The mistake is treating this as “basic” testing.
It isn’t. It’s the foundation. If this breaks, everything else breaks in worse ways.
The first flows I verify
Start to first control
If “New Game” doesn’t reliably get you playing, nothing else matters.
Pause and Resume
Pause stresses state, input routing, UI focus, and overlays.
If it’s unstable, you get bugs that look random but aren’t.
Input ownership (controller + keyboard)
On PC, mixed input is not an edge case.
It must be predictable:
- Pause opens consistently
- Navigation respects active input
- Confirm/back always respond
- Input hand-off doesn’t break UI
In this pass, mixed input caused misrouted actions (e.g. Resume opening Join In) and temporary controller lockups.
Pattern: controller + keyboard + menu = focus bugs.
Bug evidence (what matters)
I keep it simple:
- Video (10–30s): shows input, timing, outcome
- Screenshot: supports UI state
- Environment: build, platform, input device
If someone can’t see what happened immediately, the evidence isn’t good enough.
One-week workflow
- Day 1: smoke + baseline flows
- Days 2–4: run tests, expand on risk, log bugs
- Days 5–6: retest + tighten repro
- Day 7: summarise
I always repeat a baseline loop (load → control → pause → resume) at the start of each session.
It catches breakage early.
Key takeaway
Functional testing finds high-impact bugs early because it targets the systems everything depends on.
Most “random” bugs aren’t random.
They’re patterns you only see when you repeat simple flows properly.
Full case study and breakdown
This DEV version focuses on the workflow.
The full version includes:
- complete structure
- deeper examples
- full QA context and artefacts
👉 Read the full, updated article:
Top comments (0)