ISTQB CT-GaMe cheat sheet

Game testing covers functionality, plus non-functional game-specific areas: playability, balance, graphics, sound, localization, and platform compliance.

A game is a real-time interactive system: state changes every frame, so defects depend on timing, frame rate, input sequence, and hardware - not only on fixed inputs.

Deterministic vs non-deterministic behavior: physics, RNG, and network latency make exact-output comparison unreliable; use invariants, ranges, and seeded RNG instead.

Playability (fun, engagement, difficulty curve) is subjective and validated by playtesting with target players, not by pass/fail test cases.

Game balance means no dominant strategy and a fair difficulty curve; it is verified by analyzing win rates, resource economies, and progression data.

Platform certification (console/PC/mobile store requirements) is a distinct test level with mandatory checks: save data, user accounts, suspend/resume, controller disconnect, network loss.

Test levels map to game structure: unit (mechanics/formulas), integration (systems interacting), system (full build on target hardware), acceptance (publisher/platform).

Exploratory and session-based testing dominate because scripted cases cannot cover the combinatorial state space of a live game world.

Risk = probability of occurrence × impact; game risks are ranked by player-facing severity (crash, data loss, progression block) and by exposure (player count, session length).

Highest-severity game risks: save corruption, monetization/payment errors, progression-blocking bugs, online desync, and certification failures that block release.

Product risk analysis uses likelihood × impact; project risk covers schedule, hardware availability, third-party SDKs, and asset delivery delays.

Test goals derive from the risk list: each high risk needs a mitigation activity (test, review, telemetry monitoring, or playtest).

Risk-based test prioritization: cover core loop and monetization first, then progression, then cosmetic and edge content.

Use player telemetry and crash reports from earlier builds or betas as empirical input to risk probability estimates.

Goals must be measurable: e.g., 'no crash in 8-hour soak', 'frame rate ≥ target on minimum spec', 'zero blocker bugs at cert submission'.

Legal/regulatory risks (age ratings, loot box disclosure, privacy/GDPR, accessibility) belong in the risk register with compliance evidence as exit criteria.

Test design starts from the game state model: identify states, transitions, and inputs, then derive coverage of paths, boundaries, and invalid transitions.

Boundary value analysis applies to numeric game data: health, ammo, currency, inventory slots, level caps, and stack sizes (test min−1, min, max, max+1).

Combinatorial testing (pairwise/orthogonal arrays) reduces the input space of character, weapon, map, and difficulty combinations to a tractable set.

State transition testing fits menus, matchmaking, save/load, and quest progression; cover all valid transitions plus illegal ones.

Test implementation uses automation for regression (unit tests of formulas, API tests, replay scripts) and manual/exploratory for feel, graphics, and audio.

Automated game testing commonly uses scripted bots, input replay, and telemetry assertions; image/audio comparison is used for visual and sound regression.

Execution needs a test environment matrix: minimum and recommended hardware, OS versions, GPU drivers, console devkits, and network conditions (latency, packet loss).

Soak and stress tests (long sessions, memory leaks, repeated save/load) expose defects invisible in short scripted runs.

Defect reports for games must include build/version, hardware, reproduction steps, frequency, and evidence (video, log, crash dump, seed value).

Game mechanics testing verifies rules and formulas: damage calculation, cooldowns, collision, AI behavior, economy and drop rates; verify with boundary and equivalence data.

Physics and collision testing needs edge cases: high speed/tunneling, overlapping colliders, slopes, and frame-rate-dependent movement.

Sound testing covers asset presence and correct triggering (footsteps, UI, music transitions), mixing/volume levels, looping and cut-off, 3D positional audio, and missing/placeholder assets.

Graphics testing covers rendering correctness, frame rate targets, resolution and aspect ratio scaling, texture/LOD loading, shader compilation, and visual regressions versus reference screenshots.

Performance testing for graphics measures FPS, frame time, GPU/CPU load, memory, and load times on minimum and recommended specs; check for stutter and hitches.

Localization testing checks translation completeness, text overflow/truncation in UI, font and glyph support (CJK, Cyrillic, RTL), string concatenation, and culture-specific content (dates, currency, symbols, age ratings).

Localization also covers audio (voice-over sync, subtitles), text expansion (German/Russian longer than English), and hard-coded strings.

Games testing tools: test management and defect tracking (Jira, TestRail), automation frameworks and input replay, performance profilers (PIX, RenderDoc, platform GPU profilers), audio validation, screenshot-diff tools, and telemetry/crash reporting (Sentry, platform crash systems).

Tool selection follows the risk and test level: profilers for performance risk, screenshot diff for visual regression, bots for load/soak, telemetry for live risk monitoring.

Classify a tool by the artifact it inspects: frame captures → graphics; waveform/output → audio; input sequences → mechanics; string tables → localization.

Graphics capture tools (RenderDoc, PIX, platform GPU debuggers) reveal draw calls, shaders, and GPU timings; they diagnose rendering defects, not gameplay logic.

Screenshot/image-diff tools detect unintended visual changes across builds; they require tolerance thresholds because rendering is not bit-identical.

Audio tools validate asset format, loudness (LUFS), channel mapping, and event triggering; automated checks catch missing or silent assets.

Input-replay and bot frameworks reproduce mechanics defects deterministically when RNG is seeded; without seeding, replay is unreliable.

Localization QA tools compare string tables across languages, flag missing keys, and pseudo-localization exposes truncation before real translations exist.

Performance profilers report frame time, CPU/GPU breakdown, and memory; soak/load tools generate sustained sessions to expose leaks.

Crash/telemetry systems aggregate defects from live players and prioritize risk; they complement, not replace, pre-release testing.

Mechanics: verify damage/armor formulas, cooldowns, resource regeneration, drop tables, and XP curves using boundary values and seeded random sampling.

Mechanics: test collision and physics under extreme velocity, low frame rates, slopes, and overlapping colliders to catch tunneling and clipping.

Sound: check every sound event fires once, at the right time, with the right asset; verify loops, fades, ducking, and music state transitions.

Sound: measure loudness consistency (e.g., LUFS targets) and verify 3D attenuation/panning and platform audio device changes.

Graphics: test resolution scaling, aspect ratios (16:9, 21:9, 4:3), UI safe areas, HDR, and quality presets on minimum and recommended hardware.

Graphics: visual regression compares screenshots against baselines with tolerance; frame-rate and frame-time stability (1% low, stutter) are separate checks.

Localization: pseudo-localization (accented, expanded strings) finds truncation and hard-coded text before translation; verify font glyph coverage for CJK and RTL.

Localization: verify text expansion, subtitle timing, voice-over sync, number/date/currency formats, and region-specific content and rating symbols.

Derive test cases from the design's state machine and rules; each rule yields equivalence classes and boundary values (e.g., health 0, 1, max, max+1).

Pairwise/combinatorial design covers interactions among character, weapon, map, and difficulty without full cartesian explosion.

Test oracle choice: exact expected value for deterministic formulas; invariants (health never negative, currency never negative) for complex simulations.

Automation layers: unit tests for formulas, API/service tests for backend and matchmaking, replay bots for regression, manual exploratory for feel and fun.

Environment matrix must include minimum spec, recommended spec, each target platform, GPU driver versions, and degraded network (latency, jitter, loss).

Soak testing (multi-hour sessions, repeated map loads, save/load cycles) targets memory leaks, handle leaks, and save-file corruption.

Entry/exit criteria are risk-based: e.g., no open blockers, crash-free session rate above threshold, all cert checks passed.

Defect triage for games ranks by severity (crash/data loss/blocker > major > minor > cosmetic) and by reproducibility and player exposure.

Functional game testing checks rules, progression, UI, save/load, and multiplayer behavior against the design specification.

Non-functional game testing covers performance (FPS, load time), compatibility (hardware, OS, drivers), usability/playability, security, and accessibility.

Games are stateful and real-time: test cases must specify build, hardware, input timing, and network conditions to be reproducible.

Randomness must be controlled for testing: seeded RNG makes loot, AI, and procedural generation reproducible.

Playtesting answers 'is it fun/understandable'; QA testing answers 'does it work as specified'; they use different methods and metrics.

Balance testing uses data (win rates, time-to-kill, economy inflow/outflow) rather than opinion alone.

Certification/compliance testing (TRC/TCR/Lotcheck equivalents) is mandatory and has fixed pass/fail criteria per platform.

Localization, graphics, and audio are first-class test areas in games, not afterthoughts, because they are player-facing and platform-checked.