Game Testing Fundamentals and the Software Development Life Cycle
What this domain tests
This domain checks whether you can place testing correctly across a game's life cycle rather than treating it as a phase after code freeze. Expect questions on verification versus validation, test levels, milestone gates, and entry and exit criteria.
Core rules
- Verification asks whether the build matches its specification; validation asks whether it meets player and platform needs.
- Test levels: unit (code), integration (systems interacting), system (whole build), acceptance (player-facing or certification).
- Game milestones: prototype, vertical slice (one polished representative slice), alpha (feature-complete), beta (content-complete, polish and bug-fixing), release candidate, gold master, certification submission, live operations.
- Shift-left: review design documents and build testability early; do not wait for a playable build to find requirement gaps.
- Entry and exit criteria make gates objective. Alpha entry might require all features implemented and a passing smoke test; alpha exit might require no open blocker or critical defects.
Worked example
A stamina bar is scheduled for alpha. The lead sets entry criteria: the build installs on all target platforms, stamina drains and regenerates, and the UI updates. Exit criteria: all stamina cases executed, no open severity-1 or severity-2 defects, regression suite green. A defect shows stamina regenerating while the pause menu is open. That fails exit criteria, so milestone sign-off is blocked until the fix is verified and the regression suite is rerun. The reasoning is risk-based: a feature-complete milestone is not a calendar event.
Traps
Treating beta as a demo; assuming QA starts only at alpha; confusing alpha (feature-complete) with beta (content-complete); reporting test cases written as if that were execution evidence; ignoring regression after a milestone fix.