CDGT flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Verification vs validation

Verification confirms the build matches documented requirements. Validation confirms the product is fit for player use, fair, and shippable. Game testing needs both because a spec-compliant build can still be unfun or exploitable.

Alpha vs beta milestone

Alpha is feature-complete with internal testing. Beta is content-complete and feature-locked with external testers. Only critical fixes are accepted after beta, so late design changes carry high regression risk.

Shift-left testing

Moving test activity earlier in the SDLC, such as reviewing design docs and writing cases before code. Defects found in requirements cost far less to fix than those found in production or after certification.

Entry and exit criteria

Preconditions that must hold before a test phase starts and measurable conditions for ending it. Example exit: zero open S1/S2 defects and S3 count below an agreed threshold.

Equivalence partitioning

Dividing inputs into classes that should behave identically, then testing one representative per class. For currency, test zero, a normal value, and maximum, plus invalid negatives.

Boundary value analysis

Testing values at and just outside each limit: min-1, min, min+1, max-1, max, max+1. Bugs cluster at boundaries such as inventory caps, party size, and currency maximums.

State transition testing

Modeling a system as states and transitions, then covering every valid transition and every invalid transition attempt. Applied to menus, matchmaking flows, and save/load states.

Pairwise test design

A combinatorial reduction technique that covers every pair of parameter values at least once. It cuts full cross-products of resolution, GPU, and OS combinations to a tractable suite.

Traceability matrix

A mapping from requirement IDs to test case IDs. It exposes uncovered requirements before execution and shows which tests to rerun when a requirement changes.

Test case expected result

The observable, specific outcome a tester compares against actual behavior. It must be checkable, such as a displayed value or state, not a vague statement like works correctly.

Physics tunneling defect

A collision failure where a fast-moving object passes through a wall because it moves past the collider between frames. Test at maximum velocity, low frame rates, and thin geometry.

Item duplication exploit

A defect allowing players to create copies of an item through trade, mail, or interrupted transactions. It damages the economy, so economy paths need adversarial testing and server-side validation.

Save version migration

Handling saves created by older builds after a patch changes data structures. Test loading old saves, missing fields, and corrupted files to prevent progression loss on update.

Quest sequence break

A state where players can skip prerequisites or complete objectives out of order, bypassing intended gating. Test parallel quests, abandonment, and repeated turn-in for reward duplication.

Certification failure impact

A failed platform submission blocks release and can delay launch by days or weeks. Test system buttons, sign-out handling, storage limits, and network loss before submitting.

Controller disconnect handling

Required platform behavior when a controller disconnects mid-game: pause or notify the player and allow reconnection without crash or data loss. Verify with each supported controller type.

Entitlement loss handling

Behavior when a player loses rights to purchased content, such as refunds or account changes. The title must revoke access gracefully without corrupting saves or crashing.

Storage-full scenario

A required test where the save device has no free space. The title must report a clear error, avoid corrupting existing saves, and recover when space is freed.

Host migration

Transferring match authority to another peer when the host disconnects. Verify match state, rewards, and timing remain consistent, or that the match ends cleanly without duplication.

Client-side prediction

The client simulates movement locally before server confirmation. Test under latency for rubber-banding, teleporting, and hit-registration mismatch between client and server state.

Server authority

The server validates critical outcomes such as damage, currency, and position. Client-only trust enables cheating, so confirm the server rejects tampered values.

Network condition simulation

Testing under injected latency, jitter, and packet loss instead of a clean LAN. Typical profiles are 100, 200, and 400 ms with 1 to 5 percent loss.

Frame time budget

The time allowed per frame: 16.67 ms at 60 FPS and 33.3 ms at 30 FPS. Measure 1 percent and 0.1 percent low frame times, not just average FPS.

Soak testing

Running the game continuously for 8 to 72 hours to expose memory leaks, handle exhaustion, and save corruption. Track memory and object counts over the session.

Thermal throttling test

A sustained mobile or console session that checks frame rate stays above the certified floor as the device heats. Short benchmark runs miss this degradation.

Pseudo-localization

Replacing text with accented, expanded placeholder strings to expose hard-coded strings, truncation, and layout overflow before real translations are integrated.

Text expansion risk

Translated strings often grow 30 to 50 percent, especially German and Russian. Verify buttons, subtitles, and containers accommodate longer text without clipping.

Colorblind-safe cues

Gameplay information must not rely on color alone. Pair color with shape, icon, or text, and test under deuteranopia, protanopia, and tritanopia simulations.

Severity vs priority

Severity measures impact on the product, such as crash or data loss. Priority measures fix urgency. They are independent: a rare crash on a mandatory path can be high severity and high priority.

Reproducible bug report

A report containing build, platform, preconditions, exact steps, expected versus actual behavior, frequency, and evidence such as logs or video. Without steps, triage stalls.

Deduplication by root cause

Merging reports that share one underlying cause even when symptoms differ. Keep one canonical reproduction and link related reports to avoid double-counting metrics.

Defect removal efficiency

The share of total defects found before release: pre-release found divided by all defects found. A falling value signals weaker testing or escaped defects.