02 · Coverage system
A regression taxonomy for a live-service content update, and the dashboard that tracks it
Seasonal content updates on a live-service title touch a lot of surface area at once: new events, physics or balance fixes, licensed vehicle content, entitlement changes, front-end and localization strings, multiplayer. Testing all of it evenly wastes time; testing it unevenly ships regressions. I authored a 90-case plan built around a taxonomy I defined for exactly this problem: six regression categories (direct-fix confirmation, knock-on, licensing validation, area regression, build sanity, condition coverage), each case classified by priority (P0 to P3) and risk (Critical, High, Medium, Low), so the plan tells you not just what to test but what to run first if time runs out.
Every case is fully specified: objective, preconditions, numbered steps, expected result. The plan drives a linked dashboard: pass/fail by priority, by platform, by game mode, and by tester, updated live as execution happens.
Below is a build of that coverage system with sample data. Pick a platform and a build, and watch the coverage, pass rate, and per-category breakdown update. This is the actual structure of the real dashboard, with placeholder numbers standing in for the live figures.
What the six categories mean:
Direct Fix Confirmation
Confirms the exact reported bug is actually fixed, nothing more.
Knock-On
Checks that fixing one thing didn't quietly break something else nearby.
Licensing Validation
Confirms licensed driver, team, and sponsor assets display and behave correctly.
Area Regression
A wider sweep of the feature area around the change, not just the fix itself.
Build Sanity
Basic checks that the build boots and core flows work before deeper testing starts.
Condition Coverage
Tests specific edge-case states, like offline mode or mixed entitlements, not just the main path.