KDU CGT key terms

A small, fast set of checks run on every new build to confirm it is stable enough for deeper testing. A failed BVT usually sends the build straight back to the developers.

Re-running existing tests after changes to verify that previously working features still behave correctly. In games this covers mechanics, save data, UI, and online services touched by a patch.

A documented set of preconditions, inputs, and expected results that verifies one specific behavior. Good cases are independently executable and state a single, checkable outcome.

A technique that groups inputs into classes expected to behave the same way, then tests one value per class. It reduces redundant cases while keeping coverage of valid and invalid ranges.

A technique that targets values at the edges of input ranges, such as minimum, maximum, and just outside them. Defects cluster at boundaries, so these values deserve dedicated test cases.

A technique that models a system as states and the events that move between them, then tests valid and invalid transitions. It suits menus, character states, match phases, and quest progression.

A technique that tabulates combinations of conditions and the actions a system should take for each. It exposes missing or contradictory rules in logic such as damage calculation or purchase flows.

Simultaneous learning, test design, and execution where the tester probes the product without pre-scripted cases. It is effective for finding emergent issues in gameplay that formal cases miss.

A way to structure exploratory testing into time-boxed, charter-driven sessions with notes and debriefs. It makes unscripted testing measurable through coverage, duration, and defect yield.

A short statement of the mission for an exploratory session, naming what to explore and why. It guides effort without prescribing exact steps, and results are reported against it.

The repeating cycle of player action, system feedback, and reward that drives engagement. Testers verify that each step triggers correctly, that rewards persist, and that the loop cannot be broken or short-circuited.

The complete set of values describing a game at a moment, including player stats, inventory, level, and active entities. Many functional defects appear as state that is inconsistent, duplicated, or not reset correctly.

The property that saved progress is written, read, and migrated without loss or corruption. Tests cover interrupted saves, version upgrades, full storage, and cross-device transfer.

The number of rendered frames per second. Testers measure it under representative load and look for sustained drops, stutter, and pacing problems rather than only average values.

The time taken to produce a single frame, usually expressed in milliseconds. Consistent frame times matter more than a high average, because spikes cause visible stutter even when FPS looks acceptable.

Running the game under sustained load for an extended period to reveal memory leaks, degradation, and resource exhaustion. Issues often appear only after hours of continuous play.

A defect where allocated memory is never released, so usage grows over time until performance degrades or the application crashes. Soak tests with memory profiling are the usual detection method.

Verifying that the game works correctly across supported hardware, operating systems, drivers, resolutions, and input devices. It relies on a defined support matrix rather than testing every possible configuration.

The documented list of platforms, devices, and configurations a title is committed to supporting. Test coverage and certification obligations are scoped against it.

The platform holder's formal review that a submitted build meets its technical and policy requirements. Failure returns the build with violations that must be fixed and resubmitted.

The platform holder's published list of mandatory technical and behavioral requirements a title must satisfy. Testers derive compliance cases directly from each numbered requirement.

A test that verifies a specific platform requirement, such as correct handling of controller disconnect, storage-full conditions, or user sign-out. Results are evidenced for submission review.

A platform holder's written approval to deviate from a requirement, usually granted for a justified technical reason. Without a waiver, the deviation is a certification failure.

The process of delivering a candidate build to the platform holder for certification, including required metadata, declarations, and test evidence. Rejected submissions cost schedule and fees.

The delay between an input or action and its observable effect, including network transit and server processing. High latency makes actions feel unresponsive and can desynchronize players.

The failure of transmitted data to reach its destination, causing missing updates, rubber-banding, or disconnects. Testers simulate loss percentages to verify graceful degradation.

Variation in the delay between packets, which produces uneven movement and unreliable timing even when average latency is low. It is usually tested alongside latency and packet loss.

Deliberately injecting latency, jitter, packet loss, and bandwidth limits to test online behavior under poor conditions. Tools apply these profiles without requiring real long-distance connections.

Server-side logic that rewinds or predicts game state so actions taken under latency are judged fairly. Testers check that it does not create exploitable advantages or visible anomalies.

Transferring authority for a multiplayer session to another player when the original host leaves or drops. Tests verify the match continues, state is preserved, and clients reconnect cleanly.

The measured impact of a defect on the product, such as crash, blocked progress, or cosmetic issue. Severity is a property of the defect itself, independent of how urgently someone wants it fixed.

The order in which a team intends to fix a defect, balancing severity against schedule, risk, and business needs. A high-severity crash may be low priority if it occurs in cut content.

The precise, ordered actions and conditions that reliably trigger a defect. Clear steps with preconditions and observed versus expected results let developers confirm and fix the issue quickly.

The defined sequence of states a defect passes through, typically new, assigned, fixed, verified, and closed, with reopen paths. Each transition has an owner and entry criteria.

A regular meeting where new and open defects are reviewed, prioritized, assigned, and sometimes deferred or rejected. It keeps the defect backlog actionable and aligned with release risk.

The extent to which tests exercise defined targets, whether requirements, code paths, features, or platforms. It is reported as a proportion against a stated baseline so it can be interpreted.

A table linking requirements to the test cases that verify them, showing coverage and gaps. It supports impact analysis when requirements change late in development.

The number of confirmed defects per unit of scope, such as per feature, per thousand lines of code, or per test hour. It highlights risky areas and informs where to focus testing.

A build considered potentially shippable, pending final verification and approvals. Any change after it is frozen requires justification and re-testing of affected areas.

A binding contract prohibiting disclosure of confidential material such as unreleased builds, platform documentation, and test evidence. Breaching it can end a contract and carry legal liability.

Recorded proof that a test was performed and its result, such as logs, captures, or completed checklists. Certification and audits often require retained evidence for each claimed pass.