CDGT key terms

The staged process a game team follows to plan, build, test, and release software, typically spanning requirements, design, implementation, verification, and maintenance phases. Testers map their activities and entry/exit criteria onto these stages.

Predefined conditions that must be met before a test phase starts and before it can be declared complete, such as a stable build or zero open blocker defects. They make phase transitions objective rather than opinion-based.

Moving testing activities earlier in the development timeline, for example reviewing design documents or testing prototype combat before content lock. Earlier defect discovery is far cheaper than fixing issues found near release.

A small but fully playable and polished section of a game that exercises every discipline and system end to end. Testers use it to validate integration early, long before full production content exists.

A build delivered on a scheduled production date, such as a first-playable or alpha milestone, with agreed acceptance criteria. Testers verify the build meets those criteria before the milestone is signed off.

A short, fast set of smoke checks run on every new build to confirm it is stable enough for deeper testing. A failed BVT typically returns the build to the developers immediately.

A compiled, packaged version of the game produced from a specific code and content revision. Each build is uniquely identified so defects, test results, and configuration issues can be traced to exact code.

Dividing input or state space into groups where all members should behave identically, then testing one representative from each group. It reduces test count while keeping meaningful coverage.

A technique that targets values at and just outside the edges of valid ranges, such as zero gold, maximum gold, and one above maximum. Off-by-one errors cluster at these edges.

A technique that models a system as states and the events that move it between them, then designs tests for valid transitions and rejected invalid ones. It suits menus, matchmaking flows, and character states.

A technique that tabulates combinations of conditions and the expected actions for each, exposing rules that might otherwise be missed. It is useful for layered gameplay modifiers and eligibility logic.

A combinatorial technique that generates test sets covering every pair of input values at least once, rather than every full combination. It catches most interaction defects at a fraction of exhaustive cost.

A documented set of preconditions, inputs, and expected results that verifies one specific behavior. Good cases are independent, repeatable, and traceable to a requirement or design intent.

An organized collection of related test cases grouped by feature, risk, or phase, executed together. Suites support selective runs such as a combat suite or a pre-release certification suite.

A table linking requirements or design features to the test cases that cover them, revealing gaps and untested areas. It also helps assess the impact of design changes on the test plan.

The repeating cycle of player action, game response, and reward that drives engagement, such as fight, loot, upgrade, repeat. Testers verify the loop stays consistent across progression and edge states.

The rules governing how players advance through levels, unlocks, currencies, and statistics. Testing it focuses on thresholds, caps, and interactions between progression tracks that could block or trivialize content.

Verifying sources and sinks of in-game currency and items, including drop rates, prices, caps, and duplication risks. It checks that rewards and costs behave as designed under normal and exploitative play.

The per-frame timing values of an attack or action, such as startup, active, and recovery frames plus hitbox timing. Testers confirm these values match design and behave consistently under frame-rate variation.

Checking that attack hitboxes and character hurtboxes match their intended size, position, and timing. Errors cause phantom hits or missed hits that players perceive as unfair.

Verification that saved progress is written completely and restored accurately, including across versions, interruptions, and storage failures. Corruption or silent data loss is among the most damaging gameplay defects.

Deliberately probing for ways players can gain unintended advantage, such as duplication glitches, out-of-bounds access, or sequence breaks. Findings are usually treated as high severity because they affect fairness and economy.

A platform holder's mandatory list of technical and behavioral requirements a title must satisfy to be certified for release. Failures block submission and must be fixed and re-verified.

The formal process of delivering a build to a platform holder for compliance review before release. Testers pre-check requirements and prepare evidence so the submission is not rejected on avoidable issues.

A console platform holder's compliance review stage in which the submitted build is tested against mandatory requirements. A failed lotcheck returns defect reports that must be resolved before resubmission.

Verifying a title against platform, legal, and storefront rules, including controller prompts, error handling, and age-rating displays. It differs from functional testing because the criteria come from external authorities.

How a game responds when the platform pauses it, switches users, or loses focus, and how it restores state afterward. Many certification requirements define mandatory handling for these events.

An architecture where the server owns authoritative game state and clients send inputs rather than final results. It limits cheating and desync but requires validating every client action server-side.

A state where clients and server disagree about game state, producing different outcomes for different players. Testers reproduce it with induced latency, packet loss, and reconnection scenarios.

The round-trip time for data between client and server, usually measured in milliseconds. High or variable latency exposes input delay, rubber-banding, and hit registration problems.

The failure of some transmitted network packets to arrive, causing missing updates or delayed actions. Testers simulate it to verify interpolation, retransmission, and graceful recovery.

The game's behavior when a connection drops mid-session, including messaging, reconnection attempts, and state restoration. Poor handling can cause lost progress or stuck matchmaking states.

Simulating many concurrent players or service requests to measure throughput, response time, and failure points. Results inform server capacity planning and reveal bottlenecks before live launch.

Running the game or service under sustained load for an extended period to expose memory leaks, resource exhaustion, and gradual degradation. Problems that appear only after hours are its main target.

Pushing systems beyond expected limits to find breaking points and confirm graceful failure rather than crashes or corruption. It answers how the game behaves when conditions are worse than planned.

Monitoring memory use over time and across scene transitions to find allocations that are never released. Leaks often surface as late-session crashes on constrained platforms.

Frame rate is frames rendered per second; frame time is how long each frame takes. Testers track both, since spikes in frame time cause visible stutter even when average rate looks acceptable.

Agreed limits for frame time, memory, load times, and network usage on each target platform. Tests compare measured values against these limits to decide whether a build is releasable.

Verifying that translated text, audio, and assets display correctly and fit their UI, including expansion, fonts, and cultural appropriateness. It also checks that locale-specific formats and inputs behave correctly.

Replacing source strings with accented, lengthened placeholder text to expose truncation, hard-coded strings, and font issues before real translations arrive. It catches layout problems early and cheaply.

The tendency of translated strings to occupy more or fewer characters than the source language, which can overflow buttons and subtitles. Testers check the longest expected translations against UI constraints.

Meeting published accessibility guidelines for things like remappable controls, subtitles, color-independent cues, and adjustable difficulty. Testers verify both the presence and the usability of these options.

Applying filters that approximate common color vision deficiencies to check whether critical information remains distinguishable. It reveals reliance on color alone for cues such as team markers or loot rarity.

The sequence a defect passes through, typically new, assigned, fixed, verified, and closed, with possible reopen or defer states. Clear state rules prevent defects from being lost or closed prematurely.

How much a defect damages the product, judged independently of how urgently it must be fixed. It reflects functional impact, such as crash versus cosmetic mismatch.

How urgently a defect should be addressed relative to others, balancing severity with business and schedule context. A cosmetic issue on a storefront screen can be high priority despite low severity.

A regular review where defects are assessed, prioritized, assigned, and sometimes deferred or rejected. Good triage keeps the defect database trustworthy and focuses effort on release-blocking issues.

A precise, ordered description of the actions, inputs, and conditions that reliably trigger a defect. Reproducibility is the single biggest factor in how quickly a defect gets fixed.

Analyzing crash reports, logs, and memory dumps to group crashes by root cause and route them to the right owner. It converts raw crash volume into a small set of actionable defects.

Re-running tests that previously passed to confirm new changes did not break existing behavior. It is usually prioritized by risk and automated where stable and repeatable.

Using scripts and tools to execute tests and compare results without manual input, suited to stable, repetitive checks. It frees human testers for exploratory work where judgment matters.

The tooling and scaffolding that runs tests and controls the environment, including input injection, state setup, and result capture. A weak harness makes automation flaky and hard to trust.

Instrumentation that records player and system events during play, providing data on crashes, progression, and behavior. Testers use it to confirm events fire correctly and to prioritize real-world issues.

The number of confirmed defects per unit of content or code, such as per level or per thousand lines. It highlights risky areas and helps focus testing where problems concentrate.

The proportion of requirements, code paths, or gameplay features exercised by executed tests. High coverage of the wrong areas proves little, so it is read alongside risk assessment.