DEV Community

Cover image for Regression testing in game QA: a risk-based workflow that keeps releases stable
Kelina Cowell
Kelina Cowell

Posted on • Edited on • Originally published at kelinacowellqa.github.io

Regression testing in game QA: a risk-based workflow that keeps releases stable

#gamedev #testing #qualityassurance #ux

⚠️ This is a condensed version of the article.

👉 Read the full, updated version (canonical):

Regression Testing Example: Manual QA Workflow for Games | Kelina Cowell

Regression testing example based on a real manual QA workflow for games, including risk-based regression scope, matrix design, golden-path checks, and stability verification after change.

kelinacowellqa.github.io

This version summarises the regression testing workflow. The full article includes deeper QA examples, structured analysis, and full case study context.

TL;DR: regression testing in game QA

  • Workflow: risk-based regression testing → golden-path baseline → targeted checks → evidence-backed results
  • Example context: Sworn (PC Game Pass, Windows)
  • Build tested: 1.01.0.1039
  • Scope driver: external patch notes used as a change signal (no platform parity assumed)
  • Outputs: regression matrix, session logs, bug tickets, and supporting QA evidence

Regression testing workflow diagram

Regression testing workflow used to verify stability after change during a timeboxed Sworn (PC) pass.

What regression testing is in game QA

Regression testing in game QA verifies that existing behaviour still works after a change.

It is not about re-testing everything or blindly following a checklist.

A practical regression testing workflow is selective and driven by risk:

  • what changed
  • what might be affected
  • what is expensive if broken
  • what must remain stable

This is why regression testing is best treated as change-driven verification, not checklist execution.

Golden path baseline in regression testing

Every regression cycle starts with a repeatable golden-path smoke test.

In this example:

BL-SMOKE-01

cold launch → main menu → gameplay → quit → relaunch → main menu

I also include a quick audio sanity check during this flow.

If the golden path is unstable, deeper regression testing becomes unreliable.

Risk-based regression testing and change signals

Regression testing scope is driven by change signals.

In this example, I used public SteamDB patch notes:

SWORN 1.0 Patch #3 (v1.0.3.1111)

Important:

  • I did not assume platform parity
  • I used patch notes only as a risk signal

This approach is useful in manual QA when internal data is unavailable.

Regression testing matrix example (manual QA)

A regression testing matrix should be auditable.

Each line includes:

  • test check
  • side-effect probe
  • outcome
  • evidence

Example checks:

  • BL-SMOKE-01 baseline
  • BL-SAVE-01 save/continue integrity
  • STEA-103-MUSIC audio continuity
  • STEA-103-AVOL settings presence
  • BL-IO-01 input handover
  • BL-ALT-01 Alt+Tab behaviour

The goal is clear, reviewable results, not assumptions.

Save/Continue regression testing with anchors

Save systems are a high-risk regression area.

To verify reliably, I use anchors:

  • location (Wirral Forest)
  • health (60/60)
  • weapon type
  • objective text

These are checked after:

  • menu Continue
  • full relaunch

This turns vague results into repeatable verification.

QA evidence in regression testing

Regression testing requires evidence for both pass and fail results.

I capture:

  • video clips (input, timing, outcome)
  • screenshots (UI state, presence/absence)
  • session timestamps
  • environment details (platform, build, input, saves)

If results cannot be verified, they are not useful.

Example regression bug (game QA)

SWOR-6: Defeat overlay blocks Stats screen

  • Expected: Stats screen appears after Continue
  • Actual: overlay remains, Stats hidden, new run starts
  • Result: Stats cannot be reviewed
  • Repro: 3/3

This shows how regression testing surfaces flow-breaking issues after change.

Example regression probe

Patch notes referenced a music fix.

Test:
STEA-103-MUSIC

  • 10 minutes runtime
  • combat transitions
  • pause/unpause
  • level load

Result: pass (music stable)

Not applicable is a valid regression result

Patch notes referenced a Dialogue Volume slider.

On this build:

  • slider not present

Result:
STEA-103-AVOL → not applicable, with evidence

This avoids false assumptions about platform parity.

Key takeaway: regression testing in game QA

Regression testing is not full re-testing.

It is:

  • risk-based
  • change-driven
  • evidence-supported

A strong regression testing workflow:

  • protects the golden path
  • targets high-risk areas
  • verifies results clearly

This is what keeps builds stable after change.

Full article and case study

This DEV version focuses on the core workflow.

The full version includes:

  • expanded regression testing structure
  • deeper QA examples
  • full case study and evidence

👉 Read the full updated version:

Regression Testing Example: Manual QA Workflow for Games | Kelina Cowell

Regression testing example based on a real manual QA workflow for games, including risk-based regression scope, matrix design, golden-path checks, and stability verification after change.

kelinacowellqa.github.io

Top comments (0)