ISTQB CT-GaMe key terms

A structured process of evaluating a video game to find defects, verify requirements, and provide information about quality and risk to stakeholders before and after release.

The overall quality assurance discipline in game development, combining process definition, test planning, reviews, and testing activities to prevent and detect defects throughout the production lifecycle.

Testing in which real players use a build to reveal fun, usability, difficulty balance, and emotional response issues that technical testing cannot detect, usually observed or surveyed by researchers.

Verification that game features behave as specified, covering mechanics, progression, save systems, menus, scoring, and multiplayer rules against requirements and design documents.

Testing quality attributes rather than features, such as performance, frame rate stability, load times, compatibility across hardware, network latency, and accessibility characteristics.

The tuning of difficulty, economy, rewards, and opponent strength so challenges feel fair and engaging; tested by analyzing player data, difficulty curves, and playtest feedback.

The planned progression of challenge across a game, ideally rising gradually with occasional relief; testers check that it does not spike unfairly or flatten into boredom.

The system of currencies, drops, prices, and sinks inside a game; tested for exploits, inflation, unintended farming loops, and consistency between displayed and actual values.

An unintended use of game rules or defects that gives players unfair advantage, such as duplication glitches or out-of-bounds access; a priority target for security and balance testing.

Technical and procedural measures that identify players or software bypassing intended rules, including memory tampering, automated input, and modified clients, verified during security-focused testing.

Client or server protection mechanisms that prevent or detect cheating, such as integrity checks and behavioral analysis; testers verify they block known cheats without harming legitimate players.

Identifying and prioritizing product and project risks specific to games, such as platform certification failure, online instability, or monetization defects, to focus testing effort where impact is greatest.

Allocating test design and execution effort according to likelihood and impact of failure, so high-risk game areas such as monetization, saves, and networking receive deeper coverage.

A high-level description of test levels, types, techniques, environments, and exit criteria chosen for a game project, aligned with platform targets, genre, and release milestones.

A document defining scope, schedule, resources, environments, risks, and deliverables for a testing effort, typically revised at milestones such as alpha, beta, and certification submission.

A scheduled project checkpoint, such as first playable, alpha, beta, or gold master, at which build completeness and test coverage are assessed against defined criteria.

The platform holder's formal compliance review of a submitted build against technical requirements; failure blocks release, so compliance tests are planned as high-risk activities.

The final build approved for manufacturing or distribution after certification and regression closure; any later change requires a new submission and renewed verification.

Conditions that must be satisfied before a test level or cycle starts, such as a stable build, available test data, and completed smoke tests, reducing wasted test effort.

Measurable conditions agreed for ending testing, such as defect closure rates, coverage targets, and absence of open blocker defects, used to justify release decisions.

A documented method for deriving test conditions and cases, such as equivalence partitioning, boundary value analysis, decision tables, state transition testing, or combinatorial testing.

A technique modeling a system as states and events, used to test menus, character modes, matchmaking flows, and save/load sequences for illegal or missing transitions.

A technique selecting values at and around the edges of input or output ranges, effective for testing score caps, level limits, inventory sizes, and timer thresholds.

Dividing inputs or conditions into classes expected to behave the same way and testing one representative per class, reducing case count while retaining coverage of behavior.

Systematically selecting combinations of configuration factors, such as platform, resolution, input device, and language, using pairwise or higher-order coverage to control test effort.

Simultaneous learning, test design, and execution guided by charters and heuristics, well suited to games where discovery of emergent behavior matters more than scripted steps.

Structuring exploratory testing into time-boxed sessions with charters, notes, and debriefs, producing measurable coverage and reviewable evidence of what was tested.

A short mission statement for an exploratory session naming the area, risk, and intent, for example probing save corruption after mid-mission console shutdown.

A documented set of preconditions, inputs, and expected results for a specific test condition, reusable across builds and traceable to requirements or risks.

The ability to link requirements or risks to test cases and results in both directions, supporting coverage analysis and impact assessment when game features change.

Re-running selected tests after changes to confirm that modified code or content did not break previously working behavior, essential in frequent game builds.

A shallow, fast set of checks confirming a new build is stable enough for deeper testing, such as launching, loading a level, and saving successfully.

A compiled, packaged version of the game delivered for testing, identified by version number so defects and results can be tied to a specific artifact.

The measured impact of a defect on the game, such as crash, progression blocker, or cosmetic glitch, guiding fix priority independently of how urgently a fix is wanted.

The order in which a defect should be fixed, set by business and schedule considerations; a cosmetic issue on a storefront may be low severity but high priority.

The testing approach focused on rules and systems: movement, combat, physics interactions, progression, scoring, and AI behavior, verified through functional and exploratory techniques.

Verification that audio behaves correctly: music, effects, voice, mixing levels, positional audio, and synchronization with events, including mute and subtitle options.

Checking visual correctness and stability: rendering artifacts, textures, lighting, animation, resolution scaling, and frame rate behavior across supported hardware configurations.

The number of rendered images per second; testers measure stability, drops, and stutter during demanding scenes because inconsistent frame pacing harms playability.

Measuring responsiveness and resource use under realistic and peak conditions, including load times, memory growth, and network latency, to confirm the game meets targets.

Confirming the game works on supported platforms, devices, operating systems, drivers, and input methods, often using combinatorial selection of configurations.

Verifying that translated text, fonts, audio, and cultural content display and function correctly, including truncation, character encoding, text expansion, and locale-specific formats.

Testing with artificially altered text that mimics translation expansion and special characters, exposing hard-coded strings and layout overflow before real translations arrive.

Evaluating whether players with visual, auditory, motor, or cognitive needs can use the game, covering remapping, subtitles, color alternatives, and scalable interfaces.

Software that drives builds and checks results without manual input, used in games for smoke tests, telemetry validation, and repeatable regression of stable interfaces.

A scripted or AI-driven agent that plays the game to exercise paths, detect crashes, or gather balance data, complementing rather than replacing human exploratory testing.

The collection of scripts, stubs, data, and tooling that lets tests run and results be captured, including console commands and debug builds exposing internal state.

A system recording defects with reproduction steps, severity, priority, build, and status, enabling triage, trend analysis, and communication between testers and developers.

Runtime data collected from builds or players, such as crashes, progression stops, and session metrics, used by testers to find issues that manual testing missed.