KDU CGT common mistakes
KDU CGT · Understand the traps and how to avoid them.
When asked to verify a game mechanic, the candidate tests only the happy path-e.g., confirms that a jump reaches the expected height once-and never probes boundary values, state transitions, or interaction with other systems (coyote time, double jump, ceiling collision).
Candidates study mechanics as descriptions to recall rather than as systems to exercise, so they write a single confirmation step and consider the mechanic 'tested'.
What to do instead
For each mechanic, enumerate its state machine and inputs, then derive cases for each transition, boundary (zero, max, just-over-max), and cross-system interaction. Explicitly state expected behaviour per case so a pass/fail is objective.
The candidate writes test cases with vague, unverifiable expected results such as 'game works correctly', 'UI looks good', or 'performance is acceptable', so the case cannot be executed deterministically by another tester.
Candidates confuse a test idea with a test case and skip the step of converting an expectation into an observable, measurable outcome.
What to do instead
Rewrite every expected result as an observable condition with values: 'health bar shows 45/100 and turns red below 50', 'frame time stays under 16.7 ms at 1080p on the reference GPU'. If a number is unknown, mark it as a parameter to be defined, not as 'acceptable'.
The candidate reports a defect as a conclusion ('the game is broken', 'multiplayer is laggy') without reproduction steps, environment details, build number, frequency, or expected vs actual behaviour, and assigns severity and priority interchangeably.
Candidates optimise for speed and assume the reader shares their context; they also conflate 'how bad it is' with 'how soon it must be fixed'.
What to do instead
Use a fixed template: title with symptom and location, build/platform, preconditions, numbered steps, expected, actual, reproducibility (e.g., 3/5), evidence reference, severity (impact) and priority (scheduling) set independently with a one-line justification each.
The candidate treats the bug life cycle as linear and always ending in 'Closed', failing to distinguish Duplicate, Deferred, Won't Fix, Cannot Reproduce, Reopened, and Verified states, or who is allowed to move a defect into each.
Life-cycle diagrams are memorised as a list of words rather than as a workflow with entry criteria, exit criteria, and role ownership.
What to do instead
Learn the cycle as transitions with gates: what evidence is required to enter Verified (fix build retested), what triggers Reopened (fail on retest), and which role owns triage versus closure. Practise classifying sample defects into terminal states with justification.
When asked where testing sits in the SDLC, the candidate describes testing as a single phase after development, ignoring that test design starts during requirements/planning, that unit, integration, system, and acceptance levels have different owners and objectives, and that V-model or agile iteration changes entry/exit criteria.
The waterfall mental model is simple and widely repeated, so candidates default to it without mapping activities to phases.
What to do instead
Build a phase-by-phase table: for each SDLC phase, list test activities (review requirements, design cases, build harness, execute, regression), artefacts produced, and exit criteria. Be able to say which level catches which defect class (e.g., unit catches logic errors, system catches integration and end-to-end flow).
The candidate answers certification/compliance questions from general intuition-e.g., 'just make sure it runs at 30 fps'-instead of citing the platform's actual requirement categories (TRC/TCR/lotcheck-style rules on suspend/resume, user sign-out, controller disconnect, storage-full handling, network loss, parental controls).
Candidates have not studied the requirement documents and assume compliance is only about performance and crashes.
What to do instead
Study the requirement categories per platform and learn the typical test: suspend/resume mid-save, controller disconnect during play, account sign-out while in a menu, storage full during save, network loss during purchase. For each, know the required system behaviour and that failures block submission.
The candidate tests multiplayer only on a good connection with two clients on one machine, missing host migration, late join, disconnect/reconnect, desync, and authority/cheat cases.
Setting up adverse network conditions and multiple clients feels like extra work, and candidates underestimate how much of online testing is about failure and recovery rather than normal play.
What to do instead
Design a network test matrix: latency, jitter, packet loss, bandwidth limits; roles (host, client, spectator); events (join mid-match, host leaves, reconnect with state restore, simultaneous input). Verify state convergence and authority rules for each cell, and state the expected resync behaviour explicitly.
The candidate describes performance testing as 'check the FPS' and usability testing as 'ask if it's fun', without metrics, baselines, hardware profiles, or acceptance thresholds, and without separating functional from non-functional concerns.
Non-functional testing is often taught as an afterthought, so candidates lack vocabulary for frame-time budgets, percentiles, memory ceilings, load times, and heuristic usability evaluation.
What to do instead
Use concrete instruments: frame time at 1% low and average, memory peak and growth over a soak run, load time to interactive, thermal throttling over 30 minutes. For usability, apply named heuristics (feedback, consistency, error prevention, control) and record task completion time and error rate with a defined participant profile.
The candidate selects test design techniques by name rather than by fit-applying equivalence partitioning where boundary values or state transitions are needed, or claiming 'exhaustive testing' of a combinatorial input space-and cannot justify coverage.
Techniques are memorised as definitions without practice mapping them to a concrete input domain, so selection is arbitrary.
What to do instead
For each scenario, first identify the input variables and their domains, then choose: boundaries for ranges, equivalence classes for large sets, decision tables for rule combinations, state transition for sequences, pairwise for multi-factor configs. State what is covered and what is deliberately excluded with a reason.
The candidate reports metrics such as 'test cases executed' or 'bugs found' as proof of quality, without normalising (pass rate, defect density per feature, defect leakage to later phases, mean time to detect/resolve) or noting that raw counts can be gamed.
Metrics are learned as a list of terms rather than as decision tools, and candidates do not consider what behaviour a metric incentivises.
What to do instead
For any metric, state the question it answers, its formula and denominator, and a misuse risk. Prefer trends and ratios (escaped defects per release, % automated regression, reopen rate) over raw totals, and tie each metric to a decision it informs (release readiness, where to invest automation).
The candidate treats ethics as an abstract topic, failing to apply it to concrete situations: leaking pre-release builds or NDAs, sharing account credentials, using cheats or exploits on live servers, misrepresenting test coverage, or reporting a discovered security flaw publicly instead of through the responsible channel.
Ethics questions look like common sense, so candidates answer with slogans instead of identifying the stakeholders, the obligation, and the correct escalation path.
What to do instead
For each scenario, name the affected parties (employer, players, platform holder), the specific policy or agreement at stake, the immediate correct action, and the escalation route (security team, compliance contact, manager). Practise distinguishing 'allowed for testing' from 'allowed in production'.