KDU CGT cheat sheet
KDU CGT · Keep the key ideas within reach.
Game Testing Fundamentals and the Software Development Life Cycle
SDLC phases: requirements, design, implementation, testing, deployment, maintenance. Testing begins during requirements with testability review and acceptance criteria definition.
Verification asks 'are we building the product right?' (reviews, static analysis); validation asks 'are we building the right product?' (playtesting, UAT). Both are required.
V-model maps each development phase to a test level: requirements→acceptance, design→system, architecture→integration, module→unit. Game projects often use iterative/Agile instead, with vertical slices per sprint.
Test levels in games: unit (engine functions, math, state machines), integration (physics+animation, save/load), system (full build on target platform), acceptance (publisher/platform requirements, player-facing features).
Entry criteria example: build compiles, smoke test passes, feature flag enabled, test data ready. Exit criteria example: 100% of planned cases executed, no open S1/S2 defects, defect discovery rate below threshold.
Regression testing is rerun after any change; a change in a shared system (input, save format, network protocol) triggers a wider regression scope than a local UI change.
Shift-left means moving test design and automation earlier; shift-right means production telemetry, crash reporting, and live-ops monitoring. Both feed the defect backlog.
A vertical slice is a small end-to-end playable segment used to validate fun, performance, and pipeline before full production; testers should cover all systems present in the slice.
Test Design Techniques and Test Case Creation
Equivalence partitioning: divide inputs into classes where all values are expected to behave the same; one test per class plus boundary values. E.g., health 0, 1–99, 100.
Boundary value analysis: test min-1, min, min+1, max-1, max, max+1. For an inventory cap of 99, test 98, 99, 100 and for a minimum of 0 test -1, 0, 1.
Decision table: enumerate condition combinations and expected actions. For 3 boolean conditions there are 2^3 = 8 rules; collapse impossible or equivalent rules to reduce cases.
State transition testing: model states (idle, running, jumping, stunned, dead) and events; achieve state coverage (visit every state) and transition coverage (traverse every valid transition) plus invalid-transition tests.
Pairwise/combinatorial testing: for n parameters with values, generate a set covering every pair; typical reduction from full Cartesian product to O(v^2 log n) cases. Use when interactions are likely but full coverage is too costly.
Use case/flow testing: happy path, alternate paths, exception paths. For a purchase flow include insufficient currency, inventory full, disconnected mid-transaction, and duplicate submit.
A good test case has: unique ID, title, preconditions, steps, test data, expected result, actual result, priority, and traceability to a requirement or user story.
Exploratory testing uses charters and time-boxes (e.g., 60–90 minutes) with session notes; it complements scripted cases and is effective for finding emergent gameplay and usability defects.
Functional Testing of Game Mechanics and Systems
Combat/damage: verify hit detection (hitbox/hurtbox), damage formula (base + scaling − mitigation), critical multipliers, damage-over-time ticks, immunity frames, and death/respawn state transitions.
Physics: test collision layers, tunneling at high velocity, slope limits, step height, ragdoll stability, and determinism across fixed timesteps. Record frame rate when a physics defect reproduces.
Progression: XP curves, level caps, unlock gating, save/load persistence, and offline progress. Test cap boundaries and negative/overflow values.
Economy: currency sources and sinks, purchase validation, refunds, price display rounding, and duplication exploits (e.g., reconnect during transaction).
Inventory: stack limits, sorting, drag-and-drop, full inventory behavior, item binding, and persistence across sessions and platforms.
AI: perception (sight/hearing ranges), pathfinding failures, aggro and leash behavior, state machine transitions, and difficulty scaling. Test with AI debug overlays enabled.
UI/UX functional checks: menu navigation with keyboard, mouse, and gamepad; localization string overflow; focus order; pause behavior; and input remapping persistence.
Save/load: test new game, overwrite, corrupt save, version migration, cloud sync conflict, and save during critical moments (mid-cutscene, mid-transaction).
Non-Functional Testing: Performance, Compatibility, and Usability
Frame time budget: at 60 FPS each frame has 16.67 ms; at 30 FPS 33.33 ms. Measure CPU main thread, render thread, GPU, and memory separately; a single spike above budget causes visible hitching.
Performance metrics: average FPS, 1% low and 0.1% low FPS, frame time percentiles (p95, p99), memory peak, load times, and streaming stalls. Report hardware, build, scene, and settings with every result.
Soak/stability testing runs long sessions (e.g., 8–24 h) to detect memory leaks, handle leaks, and thermal throttling; compare memory at start, midpoint, and end.
Compatibility matrix axes: OS versions, GPU vendors/drivers, CPU tiers, RAM, storage type, screen resolutions/aspect ratios, input devices, and platform firmware. Prioritize by market share and support policy.
Usability heuristics for games: clear feedback, consistent controls, readable HUD, adjustable difficulty/accessibility, minimal downtime, and recoverable errors. Measure with task success rate, time-on-task, and error rate.
Accessibility checks: remappable controls, subtitles with size/background options, colorblind modes, screen reader support, motion reduction, and hold-to-toggle alternatives.
Localization testing: text expansion (German/Finnish), right-to-left layout, font glyph coverage, date/number formats, voice-over sync, and culturally sensitive content.
Compatibility defect triage: reproduce on minimum spec first; if only on a specific driver, capture driver version and GPU model and file against the compatibility component.
Platform Certification and Compliance Testing
Certification (TRC/TCR/lotcheck) is a pass/fail gate before release; a failed submission can delay launch and incur resubmission fees. Test against the current published requirements for each platform.
Common requirement areas: user account and sign-in, save data and cloud storage, controller disconnect/reconnect, suspend/resume, network loss handling, parental controls, and error messaging.
Achievements/trophies: verify unlock conditions, ordering, hidden flags, and that no achievement is unobtainable. Test on a clean profile and an existing profile.
Storage: verify behavior when storage is full, when the device is removed, and when save data is corrupted or from a newer version. Never lose user data silently.
Network compliance: correct handling of offline start, reconnection, and service outages; display platform-prescribed error dialogs and do not hang on a blocking wait.
Store metadata and packaging: correct SKU, region, age ratings, entitlements, and patch size limits. Verify the submitted build is the tested build (hash match).
Compliance evidence: keep a requirement-to-test traceability matrix and logs/screenshots per requirement; auditors may request them.
Day-one patch and live updates must also pass certification; plan a buffer between certification pass and launch.
Multiplayer, Network, and Online Service Testing
Latency and jitter: simulate 50/100/200/400 ms RTT and jitter; verify client prediction, server reconciliation, and interpolation keep movement acceptable.
Packet loss and reordering: test 1%, 5%, 10% loss and duplicate/reordered packets; confirm graceful degradation and no desync or exploit.
Authority model: server-authoritative checks prevent client cheating; test by modifying client values (speed, ammo, currency) and confirming server rejection.
Matchmaking: test skill/region/latency buckets, party sizes, backfill, cancel during search, and timeout behavior. Verify no cross-region matches beyond policy.
Session lifecycle: create, join, leave, host migration, reconnect, and teardown. Verify resources are released and no ghost sessions remain.
Load and scale: ramp concurrent users to expected peak plus headroom; measure matchmaking time, error rate, and queue depth. Use realistic client behavior, not synthetic pings only.
Online services: login, entitlement checks, leaderboards, cloud saves, and store transactions. Test service degradation and maintenance windows with clear player messaging.
Security: validate input on server, rate-limit requests, protect tokens, and test for replay and duplication attacks. Log and alert on anomalies.
Defect Reporting, Tracking, and Bug Life Cycle
A defect report includes: ID, title, build/version, platform, environment, preconditions, steps to reproduce, expected vs actual, severity, priority, attachments (logs, video, save), and reproducibility (always/intermittent/once).
Severity measures impact (S1 crash/data loss/blocker, S2 major feature broken, S3 minor, S4 cosmetic). Priority measures urgency for fixing; severity and priority are independent.
Bug life cycle: New → Assigned → In Progress → Fixed → Ready for Test → Verified → Closed. Alternate paths: Reopened, Deferred, Duplicate, Not a Bug, Cannot Reproduce.
A good title states the symptom and location: 'Crash when opening inventory with 99 items on PS5 build 1.2.3'. Avoid vague titles like 'inventory broken'.
One defect per report; do not bundle unrelated issues. Attach the minimal reproduction and the earliest build where it occurs.
Triage meeting: product, QA, and dev agree severity, priority, owner, and target milestone. Track aging defects and reopen rate.
Defect metrics: defect density (defects per feature/KLOC), discovery rate, fix rate, reopen rate, average age, and escaped defects found in production.
Duplicate and cannot-reproduce handling: link to the canonical bug, record environment details, and keep the report open if intermittent until evidence is conclusive.
Test Management, Tools, and Metrics
Test plan contents: scope, objectives, approach, environments, schedule, resources, risks, entry/exit criteria, and deliverables. Review and baseline before execution.
Traceability matrix links requirements → test cases → defects → results; coverage = covered requirements / total requirements. Report uncovered high-risk requirements explicitly.
Risk-based testing: rank features by likelihood × impact; allocate more test effort to high-risk areas (monetization, saves, networking, certification).
Tools: test management (TestRail, Jira/Xray, Zephyr), defect tracking (Jira, Bugzilla), automation (Unity Test Framework, Unreal Automation, Appium for mobile), performance (PIX, RenderDoc, profilers), network simulation (clumsy, tc netem).
Metrics: test execution progress (% planned run), pass/fail rate, defect find/fix rates, defect density, MTTR, test coverage, and escaped defect count. Avoid vanity metrics; pair each with a decision.
Build and environment management: version control, CI pipelines, artifact repositories, and device farms. Every test result must reference a build hash and environment.
Estimation: use historical velocity and test case counts; add buffer for regression and certification. Track actual vs estimated to calibrate.
Reporting cadence: daily stand-up status, weekly quality report, and release readiness review with open risks and residual defect list.
Professional Ethics and Industry Practices
Report defects honestly and completely; never hide, downgrade, or delete a defect to make a milestone look better. Document risks when a release decision overrides QA.
Confidentiality: do not disclose unreleased builds, source, roadmaps, or player data. Follow NDA and platform confidentiality terms.
Player data privacy: handle PII and telemetry per GDPR/CCPA and platform policy; minimize collection, secure storage, and honor deletion requests.
Avoid conflicts of interest: disclose outside work, do not test competitors' confidential builds, and do not use insider information for trading or leaks.
Respect test participants: informed consent, ability to stop, no deception that causes harm, and fair compensation. Follow an ethics review for user research.
Credit collaboration: do not plagiarize test cases or tools; respect licenses (open source, engine EULAs) and attribute third-party assets.
Whistleblowing and escalation: report safety, harassment, or compliance violations through proper channels; retaliation is prohibited.
Professional development: keep current with platform requirements, accessibility standards, and testing techniques; share knowledge and mentor junior testers.