ISTQB CT-GaMe common mistakes
ISTQB CT-GaMe · Understand the traps and how to avoid them.
Treating game testing as identical to classic business-software testing and answering that the same functional, non-functional, and structural test types apply unchanged, without naming game-specific concerns such as gameplay balance, fun/playability, or platform certification.
Candidates study CTFL first and reuse its vocabulary verbatim; the syllabus deliberately extends the fundamental test process with game-specific targets (gameplay, graphics, sound, localization, platform compliance), so a generic answer looks correct but misses the marks.
What to do instead
Before answering any 'which test type applies' question, explicitly map the scenario to game-specific quality characteristics: gameplay/balance, graphics, audio, localization, performance under load, and platform certification. Learn the syllabus list of game-specific test targets and practise naming at least two game-specific concerns in every 'basic concepts' answer.
Confusing the terms 'game mechanics', 'gameplay', and 'game rules' and using them interchangeably in questions about what is being tested, or claiming mechanics testing is only about code-level logic.
The words overlap in everyday speech, so candidates answer from intuition rather than from the defined distinctions; the exam tests whether you know that mechanics are the implemented rules and interactions whose emergent behaviour is gameplay.
What to do instead
Write one-line definitions in your own words for each term and a concrete example per term (e.g., jump height and cooldown as mechanics, the resulting feel of movement as gameplay). When a question asks what is tested, decide first whether the target is a defined rule, an emergent player experience, or a technical subsystem, then answer.
Performing risk analysis only at project start and answering that risk-based testing ends once the test plan is approved, ignoring that game risks change with each build, patch, and platform.
Classic risk-based testing teaching emphasises initial risk identification; candidates then forget the iterative nature of game development, where feature churn and balance changes constantly shift likelihood and impact.
What to do instead
Frame every risk answer as a cycle: identify, analyse (likelihood x impact), prioritise, mitigate via test effort, and re-evaluate at each iteration or milestone. In scenario questions, state explicitly when the risk list would be revisited (new build, content drop, platform submission) and how test effort would be reallocated.
Listing only technical risks (crashes, performance) or only business risks (missed launch date) when asked to determine risks and goals, omitting player-facing and compliance risks such as unbalanced difficulty, exploitable economies, age-rating violations, or store-certification failure.
Candidates default to the risk categories they memorised for business software and do not transfer them to the game domain, where monetisation, online safety, and platform holder requirements are major risk sources.
What to do instead
Build a personal risk checklist with categories: technical, gameplay/balance, content, monetisation/economy, online/multiplayer, legal and age rating, platform certification, and localization. In any risk question, scan the checklist and name risks from at least three categories with a likelihood and impact judgement.
Describing test design as writing test cases only from the requirements document, and failing to include exploratory, experience-based, and play-testing approaches that are central for finding fun and balance defects.
Candidates trained on specification-based techniques assume every test must trace to a written requirement; games often have no complete specification for feel and balance, so purely document-driven answers are incomplete.
What to do instead
Present a layered design: specification-based techniques (equivalence partitioning, boundary values, decision tables, state transition) for rules and UI, plus experience-based and exploratory charters for gameplay and balance, plus playtesting with real players. State which layer you would use for a given feature and why.
Ignoring combinatorial and state-based aspects of game testing, such as not applying state transition testing to menus, save/load, matchmaking, or player progression, and not considering configuration coverage across devices, input methods, and graphics settings.
Games are heavily stateful and configuration-rich, but candidates reduce test design to input/output partitioning of single screens, so they miss the transitions and configuration matrix that generate most defects.
What to do instead
For any feature question, ask what states exist and what transitions and invalid transitions are possible; draw a state model. Separately list a configuration matrix (platform, OS, GPU, resolution, input device, language, save state) and choose pairwise or risk-based sampling. Mention save/load and interrupted-transition cases explicitly.
Answering execution questions by describing only manual play sessions, without mentioning build/version control of test artefacts, defect reproduction data (build number, platform, save file, log, video), regression suites, or when to automate.
Candidates equate game testing with playing the game and undervalue the discipline that makes defects actionable and regressions catchable; the syllabus expects structured execution and reporting.
What to do instead
Memorise a defect report checklist: build/version, platform and hardware, steps, expected vs actual, reproducibility, logs, screenshot or video, save file, and severity/priority. In execution answers, mention smoke tests on new builds, targeted regression around changed areas, and automation for stable, high-frequency checks such as build verification and performance benchmarks.
Treating graphics testing as only 'does it look right', and failing to name concrete checks such as resolution and aspect ratio handling, frame rate and frame time, texture and LOD streaming, visual artefacts (clipping, z-fighting, popping), UI scaling, colour and accessibility options, and platform-specific rendering paths.
Visual quality feels subjective, so candidates give vague answers; the exam expects specific observable properties and measurable criteria.
What to do instead
Prepare a graphics checklist: supported resolutions and aspect ratios, UI safe areas, frame rate targets and stability, loading and streaming hitches, texture quality settings, shadows and effects, artefacts, HDR and colour-blind modes, and comparison against reference screenshots on each target platform. Pair each check with how you would observe or measure it.
Reducing sound testing to 'check that audio plays', omitting synchronization with animation and events, mixing and volume levels, spatial audio and occlusion, looping and transitions, missing or duplicated cues, subtitle and caption alignment, and platform audio-device differences.
Audio is easy to under-specify and candidates lack a mental model of the audio pipeline, so they cannot generate specific test conditions.
What to do instead
Learn the audio checklist: event-to-sound mapping, latency and lip-sync, looping seams, ducking and mixing priorities, 3D positioning and attenuation, silence and missing-asset fallbacks, voice-over language variants, and subtitle timing. For each, state a concrete way to detect failure (listen on multiple output devices, capture waveform timing, verify cue tables against the event list).
Handling localization as pure translation review, missing functional localization defects: text overflow and truncation in UI, font and character-set support, right-to-left layout mirroring, string concatenation and plural/gender rules, culture-specific content and age-rating differences, audio and lip-sync per language, and locale-specific date, number, and currency formats.
Candidates think localization equals proofreading, so they do not consider that localized builds are separate configurations requiring their own functional and layout testing.
What to do instead
Build a localization test checklist covering pseudo-localization to expose hard-coded strings and overflow, font and glyph coverage per language, layout mirroring for RTL, plural and gender handling, concatenated and variable-inserted strings, localized audio and subtitles, and regional compliance. In answers, state that each supported language is a test configuration and name at least three concrete checks.
Naming testing tools generically ('use a bug tracker', 'use automation') without linking tool categories to game-specific purposes, or claiming a specific commercial tool's features from memory when unsure.
Candidates want to show tool awareness but lack a category framework, so answers are vague; guessing vendor features also risks stating wrong facts.
What to do instead
Learn tool categories and what each is for: test management and defect tracking, automated build verification and smoke tests, unit and integration frameworks, performance and frame-time profilers, memory and crash analysis, network condition simulation, input replay and record/playback, automated UI and image comparison, localization and pseudo-localization tools, and platform certification test suites. Answer by category and purpose, and only name a product when you are certain of its function.