CDGT common mistakes
CDGT · Understand the traps and how to avoid them.
Treating the SDLC phases as a strict waterfall and placing all testing after content-complete, so the candidate answers questions about test entry criteria, shift-left activities, and stage-gate sign-off by saying testing 'begins once the build is stable' rather than describing per-phase test levels and exit criteria.
Many candidates come from manual QA roles on shipped titles where they only saw the late-stage test pass, so they have no mental model of how test planning, unit/integration verification, and certification readiness map onto milestones like first playable, alpha, beta, and release candidate.
What to do instead
Build a one-page milestone map: for each phase (concept, pre-production, production, alpha, beta, release candidate, post-launch) list the test level, the entry criteria, the exit criteria, and who signs off. Practice explaining where regression suites, soak tests, and certification submissions sit relative to content lock and code lock.
Choosing test design techniques by habit rather than by input model: the candidate writes only example-based positive cases for a combat damage formula and never derives boundary values, equivalence partitions, or decision-table cases for the modifier interactions, so they miss the off-by-one and stacked-multiplier defects the question is probing.
Candidates memorize definitions of boundary value analysis and decision tables but never practice applying them to game-specific numeric systems, so under time pressure they default to listing 'normal attack, critical hit, miss' examples.
What to do instead
For any numeric or rule-based system, practice a fixed routine: identify inputs and ranges, partition them, pick boundaries and just-inside/just-outside values, then build a decision table for interacting conditions (buffs, resistances, caps). Write the resulting cases with explicit input values and expected outputs so the technique is visible in the answer.
Writing test cases that assert only that a feature 'works' or that the screen 'displays correctly', with no preconditions, no concrete input data, and no observable expected result, so the case cannot be executed reproducibly or judged pass/fail.
Candidates draft cases the way they would describe a feature to a colleague, assuming shared context about save state, character level, and inventory, and they confuse a test idea with an executable test case.
What to do instead
Use a fixed template for every authored case: unique ID, title, priority, preconditions (save file, character state, build/platform), numbered steps with exact inputs, and an expected result stated as an observable, checkable outcome (value, state flag, log line, visual state). Self-check by asking whether a different tester on a different machine could reach the same verdict.
Testing gameplay systems only through the happy path of a single mechanic in isolation, ignoring cross-system interactions such as inventory plus crafting plus save/load, or economy sinks plus progression gating, so the candidate misses the integration defects the questions describe.
Candidates compartmentalize features the way the bug tracker does, and isolated feature testing is easier to script and report, so interaction coverage is never built into their routine.
What to do instead
For each system under test, list the systems it reads from and writes to, then author at least one integration case per interface: consume an item during crafting then reload the save; complete a purchase at the exact currency boundary; trigger a quest reward while the inventory is full. Frame expected results in terms of persistent state after save/load.
Answering platform certification questions from general memory of 'console rules' instead of distinguishing requirement categories, so the candidate conflates things like achievement/trophy behavior, user account and save-data handling, suspend/resume and power transitions, and controller-disconnect handling, and cannot state which are mandatory versus recommended.
Certification requirements (TRC, TCR, XR, Lotcheck-style checklists) are long, revision-specific, and rarely studied in structured form, so candidates rely on vague recollection and treat all requirements as equally weighted.
What to do instead
Build a category checklist per platform family covering: account and profile handling, save data and cloud sync, achievements/trophies and their timing rules, network loss and reconnection, suspend/resume and standby, controller disconnect/reconnect, parental controls and region settings, and error messaging. For each item note mandatory vs recommended and the typical evidence a submission requires. Study the current published requirements for the platform version in the question rather than generic memory.
Treating multiplayer testing as single-player testing with extra clients: the candidate verifies that two players can join a session but never plans for host migration, late join and reconnect, packet loss and latency variation, desync between clients, or authoritative-server validation, so they cannot answer questions about state divergence or exploit paths.
Reproducing network conditions requires tooling and a second machine or simulated clients, so candidates without that experience reason about multiplayer from the player's perspective and never consider the server's view of truth.
What to do instead
Structure multiplayer test plans around four axes: topology (peer-to-peer, listen server, dedicated server), adverse conditions (latency, jitter, packet loss, bandwidth cap), lifecycle events (join, leave, host migration, reconnect, suspend), and authority (what the client may predict versus what the server validates). For each case state the expected converged state on all clients and what the server logs should show.
Reporting performance and stability findings as single anecdotal observations ('it lagged on the third level') with no measurement method, hardware baseline, or duration, and omitting compatibility matrices entirely, so the candidate's answers cannot distinguish a real regression from environmental noise.
Candidates have seen frame-rate complaints but never captured frame-time data, memory profiles, or a soak-test duration, and they assume 'it ran on my PC' generalizes to the compatibility surface.
What to do instead
Always specify the measurement: metric (frame time percentiles, memory high-water mark, load time, crash-free session length), tool (in-engine profiler, platform capture, automated benchmark run), hardware and build baseline, scenario, and duration. For compatibility, define the matrix by platform, OS/firmware version, GPU/CPU tier, resolution, storage type, and input device, and state which cells are in scope and why.
Treating localization as translation review only and accessibility as an afterthought: the candidate checks that strings appear in the target language but ignores text expansion and truncation, font and glyph coverage, right-to-left layout, concatenated strings and placeholder ordering, and never evaluates subtitles, remapping, colorblind modes, or difficulty options against accessibility guidelines.
Localization and accessibility are often handled by specialist teams late in production, so general testers see only the surface artifacts and do not know the failure classes (overflow, missing glyphs, untranslated fallbacks, non-remappable inputs) or the relevant guideline structure.
What to do instead
For localization, test with pseudo-localization and the longest-string language, check every UI surface for truncation and overlap, verify placeholder and plural handling, font glyph coverage, RTL mirroring, and audio/subtitle sync. For accessibility, work through a checklist aligned to established guidelines: subtitle sizing and speaker identification, full input remapping, hold-to-toggle alternatives, colorblind-safe cues paired with shape or audio, UI scaling, and screen-reader or text-to-speech coverage where required.
Filing defects that describe a symptom without reproducible steps, build identifier, platform, or frequency, and assigning severity by gut feel, so the candidate's answers confuse severity with priority and cannot justify a triage decision when asked who should fix what first.
Candidates write reports in a hurry at the end of a session, omit the environment because it is obvious to them, and have never had to defend a severity rating against a producer or lead.
What to do instead
Use a report template: title stating the observable failure, build and platform, preconditions, exact reproduction steps, expected versus actual, frequency (for example 3 of 10 attempts), evidence (log, clip, save file), and severity with justification. Learn the distinction: severity reflects impact on the game (crash, progression blocker, cosmetic), priority reflects scheduling and business context. Practice triage scenarios where a low-severity, high-visibility bug competes with a rare progression blocker.
Describing automation as 'automate the regression suite' without selecting candidates by stability and value, and reporting test metrics as raw counts (cases executed, bugs filed) with no pass rate trend, coverage basis, or defect detection effectiveness, so the candidate cannot answer questions about what to automate, flakiness, or which metrics mislead.
Candidates equate automation with volume and assume more executed tests means better quality, without experience of maintenance cost, brittle UI-driven tests, or metrics that incentivize the wrong behavior.
What to do instead
Apply a selection rule: automate stable, deterministic, high-frequency, data-driven checks (save/load integrity, economy calculations, config validation, smoke and build-verification suites); keep exploratory, feel-based, and rapidly changing features manual. Track flaky-test rate and quarantine failures rather than retrying silently. When discussing metrics, pair counts with rates and trends (pass rate over builds, escaped-defect rate, mean time to detect), and explain what each metric does not capture.