Determining risks and goals for gaming software
What this domain tests
Risk-based testing for games: identifying product and project risks, scoring them, and converting them into test goals and measurable objectives.
Product versus project risk
Risk is probability multiplied by impact. Product risks threaten quality: crashes and progression blockers, save corruption, balance exploits, monetisation errors such as double charges or missing grants, matchmaking and online failures, frame-rate and load-time problems, hardware and OS compatibility, accessibility, localisation defects, IP/legal and age-rating non-compliance, and certification failures. Project risks threaten delivery: scope creep, asset-pipeline delays, engine or tool instability, outsourced content and staff turnover.
From risk to goals
Risk analysis (identify, assess, prioritise) feeds risk control (mitigate, monitor). High risk means deeper, earlier and more repeated testing - not simply more test cases. Set quality goals and test objectives that can be measured: crash-free session rate, 99th-percentile frame time, purchase success rate, progression completion, and defect leakage after release.
Worked example
A mobile free-to-play title sells gems. Risk: the store purchase completes but the grant is lost when the connection drops. Likelihood is moderate; impact is severe (revenue loss, refunds, store sanctions). Score: high, so mitigate - test the interrupt-and-resume path, verify server-side receipt validation and idempotent grant logic, and monitor the purchase funnel after release. Reasoning: business impact drives both test depth and production monitoring.
Traps that cost marks
- Scoring risks numerically with no documented rationale.
- Listing only functional risks and ignoring legal, certification and live-ops risks.
- Treating "risk" as a synonym for "defect".
- Setting goals such as "test thoroughly" that cannot be measured.
- Never re-assessing risks as the build and schedule change.