Game Regression Testing
Regression testing is not about finding new bugs. It is about confirming that old bugs have not returned and working scenarios have not broken after recent changes. Without it, every new patch is a lottery: the developer fixes a character collider, and the save system breaks because they both depend on the same ScriptableObject-container, which nobody touched, but component initialization order changed.
Why regression in games is harder than in regular software
In a regular web application, regression test is an API request and response check. In a game "animation broke on character death" means: launch the scene, enter combat mode, reduce HP to zero, wait for animation trigger, verify that Animation Controller switched to Death state, that Collider disabled at the right moment, that death UI appeared without artifacts.
This is hard to automate completely. Therefore, game regression usually works in hybrid model: autotests cover deterministic logic (damage calculations, inventory, progression, network protocols), manual testing covers visual and behavioral scenarios.
Specific case: in mobile RPG after dialog system update, "conduct 10 conversations" achievement trigger broke. Autotest on DialogueManager.OnDialogueComplete passed — the event was being called. But the counting logic moved to another class and lost event subscription. Manual test found it in 10 minutes; autotest found nothing because it checked only event invocation, not final achievement counter state.
How regression suite is built for a game
Foundation — regression pack: set of test cases covering critical paths. For each patch we define scope of impact: which systems are affected by changes? If enemy AI was fixed — we test not only AI but everything it interacts with: NavMesh, aggression, loot, achievements related to enemies.
For automation we use Unity Test Framework in Play Mode with tests covering:
- Critical game-loop scenarios (spawn → combat → death → respawn)
- Inventory and crafting at boundary values
- Save and load with different data versions
- Network events (via mock Photon-client or Mirror NetworkManager in offline-mode)
Tests run via Unity Cloud Build or local CI (Jenkins, GitHub Actions) on each commit to main/develop. If suite of 200 tests passes in 8 minutes — acceptable. If in 40 minutes — need to split tests into fast (smoke) and slow (full regression), run by schedule.
For mobile platforms, regression run additionally passes on real devices via Firebase Test Lab or physical device farm — emulator doesn't reproduce OpenGL ES/Vulkan specifics and doesn't test thermal throttling.
Prioritization and scope
Not every bug fix requires full regression run. We use risk matrix: how much does change affect shared systems (EventBus, SceneManager, SaveSystem)? If only UI widget of one screen was fixed — smoke + screen-specific regression is enough. If SaveSystem was changed — full run is mandatory.
Important artifact — regression baseline: saved game states for each typical scenario. This allows starting test not from game start, but from needed point — saves hours of manual testing.
After each patch release, we update regression pack: bugs found in this cycle become new test cases. So suite grows and covers real regression risks, not hypothetical ones.
| Scale | Estimated Run Time |
|---|---|
| Smoke regression (50–80 cases) | 2–4 hours |
| Partial regression (scope of impact) | 1–3 days |
| Full regression pack | 3–7 days |
| Automated CI regression (each build) | 15–60 minutes |
Cost of forming regression pack and setting up CI is calculated after project analysis.