DEV Community: Kelina Cowell

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

Kelina Cowell — Mon, 29 Dec 2025 09:00:00 +0000

⚠️ 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 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

Exploratory testing on mobile: the messy checks that find real bugs

Kelina Cowell — Mon, 22 Dec 2025 09:00:00 +0000

⚠️ This is a condensed version of the article.

👉 Read the full, updated version (canonical):

Exploratory Testing in Mobile Apps: QA Workflow & Real Bug Examples | Kelina Cowell

Exploratory testing in mobile apps using real QA workflows and bug examples. Learn session structure, risk-based testing, and how exploratory testing finds issues scripted checks miss.

kelinacowellqa.github.io

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

TL;DR: exploratory testing in mobile QA

What it is: exploratory testing is a manual QA approach where test design, execution, and analysis happen together
Platform focus: mobile apps (Android), where interruptions and lifecycle changes create real-world bugs
Approach: short, timeboxed sessions using charters, controlled variation, and risk-based decisions
Outputs: reproducible bugs, clear bug reports, and QA evidence with enough context to diagnose issues

Exploratory testing in mobile apps: chartered, timeboxed sessions with controlled variation, producing defects, notes, bug reports, and evidence.

What exploratory testing is in mobile QA

Exploratory testing in mobile QA is not “random testing”.

It is a structured manual testing approach where:

test design
test execution
and analysis

all happen at the same time.

Instead of following predefined test cases, I:

define a test charter
observe behaviour
adapt based on risk and system response

The key difference from scripted testing is adaptability under real conditions.

Why exploratory testing matters in mobile apps

Mobile apps rarely fail under ideal conditions.

They fail when real users interact with them.

Common mobile QA risks include:

interruptions (calls, notifications, alarms)
backgrounding and resuming apps
network switching during critical flows
UI scaling issues across devices

Exploratory testing in mobile apps targets these real-world scenarios directly, instead of assuming a clean user journey.

Mobile exploratory testing workflow (practical example)

1. Test charters, not scripts

A test charter defines intent, not steps.

Example:

Explore reward claim behaviour under interruptions.

This keeps sessions focused while allowing flexibility.

2. Timeboxed exploratory sessions

Effective exploratory testing sessions are short:

20 to 45 minutes

Timeboxing:

prevents unfocused wandering
forces prioritisation
improves consistency across sessions

3. Controlled variation

A core principle of exploratory testing in mobile QA is:

change one variable at a time

Examples:

lock/unlock state
background/resume
network changes
rotation
app restart

This keeps results interpretable and bugs reproducible.

Common mobile bugs found through exploratory testing

Exploratory testing is effective at finding low-frequency, high-impact bugs:

soft locks blocking progression
state inconsistencies after lifecycle changes
audio or visual desync after OS events
UI issues in specific device contexts

These bugs often do not appear in scripted testing because scripted flows assume ideal conditions.

Example: Android reward claim soft lock

In an Android exploratory testing session:

repeatedly backgrounding the app
while a reward animation was running

caused a soft lock.

Result:

UI remained visible
reward state never completed
progression blocked

This issue only appeared under lifecycle interruption conditions.

That is exactly why exploratory testing in mobile QA is necessary.

Bug evidence in exploratory testing

Exploratory testing requires strong evidence to make findings actionable.

I capture:

screen recordings during the session
notes on device and network state
reproduction steps while context is fresh
expected vs actual behaviour

A useful exploratory bug report answers:

What changed?
What happened?
What should have happened?
Can it be reproduced?

Key takeaway: exploratory testing in mobile QA

Exploratory testing is structured testing, not random behaviour.

In mobile QA, it matters because:

users interrupt flows
apps change state constantly
real-world conditions introduce timing issues

A good exploratory workflow turns unpredictable behaviour into reproducible bugs.

Full article and case study

This DEV version focuses on the core workflow.

The full version includes:

expanded structure
deeper QA examples
full case study and evidence

👉 Read the full updated version:

Exploratory Testing in Mobile Apps: QA Workflow & Real Bug Examples | Kelina Cowell

Exploratory testing in mobile apps using real QA workflows and bug examples. Learn session structure, risk-based testing, and how exploratory testing finds issues scripted checks miss.

kelinacowellqa.github.io

Evidence and case study links

Rebel Racing: Charter-based Exploratory & Edge-Case Testing (full artefacts and evidence):

https://kelinacowellqa.github.io/Manual-QA-Portfolio-Kelina-Cowell/projects/rebel-racing/
QA Chronicles Issue 2: Rebel Racing:

https://kelinacowellqa.github.io/QA-Chronicles-Kelina-Cowell/issues/issue-02-rebel-racing

This DEV version focuses on workflow. The case study expands into full QA artefacts, test runs, and evidence.

Functional testing: the boring basics that catch real bugs

Kelina Cowell — Sun, 21 Dec 2025 21:49:54 +0000

⚠️ This is a condensed version of the article.

👉 Read the full, updated version (canonical version):

Game QA Functional Testing Workflow (Battletoads PC Case Study) | Kelina Cowell

Game QA functional testing workflow using a real Battletoads PC case study. Learn manual QA workflows, bug reporting, and reproducible defect evidence.

kelinacowellqa.github.io

This DEV version summarises the workflow. The full version includes complete structure, deeper examples, and full QA context.

TL;DR

What it is: a game QA functional testing workflow for timeboxed solo passes
Backing project: Battletoads (PC Game Pass), one-week pass
Approach: validate start-to-control and Pause/Resume first, then expand where risk appears
Outputs: pass/fail results, reproducible bug reports, and short evidence clips

Game QA functional testing workflow used during a one-week Battletoads (PC) pass.

What functional testing is (in game QA)

Functional testing answers one question:

Does the game do what it claims to do, end-to-end?

I validate core flows, confirm expected behaviour, and write issues so a developer can reproduce them without guessing.

The mistake is treating this as “basic” testing.

It isn’t. It’s the foundation. If this breaks, everything else breaks in worse ways.

The first flows I verify

Start to first control

If “New Game” doesn’t reliably get you playing, nothing else matters.

Pause and Resume

Pause stresses state, input routing, UI focus, and overlays.

If it’s unstable, you get bugs that look random but aren’t.

Input ownership (controller + keyboard)

On PC, mixed input is not an edge case.

It must be predictable:

Pause opens consistently
Navigation respects active input
Confirm/back always respond
Input hand-off doesn’t break UI

In this pass, mixed input caused misrouted actions (e.g. Resume opening Join In) and temporary controller lockups.

Pattern: controller + keyboard + menu = focus bugs.

Bug evidence (what matters)

I keep it simple:

Video (10–30s): shows input, timing, outcome
Screenshot: supports UI state
Environment: build, platform, input device

If someone can’t see what happened immediately, the evidence isn’t good enough.

One-week workflow

Day 1: smoke + baseline flows
Days 2–4: run tests, expand on risk, log bugs
Days 5–6: retest + tighten repro
Day 7: summarise

I always repeat a baseline loop (load → control → pause → resume) at the start of each session.

It catches breakage early.

Key takeaway

Functional testing finds high-impact bugs early because it targets the systems everything depends on.

Most “random” bugs aren’t random.

They’re patterns you only see when you repeat simple flows properly.

Full case study and breakdown

This DEV version focuses on the workflow.

The full version includes:

complete structure
deeper examples
full QA context and artefacts

👉 Read the full, updated article:

Game QA Functional Testing Workflow (Battletoads PC Case Study) | Kelina Cowell

Game QA functional testing workflow using a real Battletoads PC case study. Learn manual QA workflows, bug reporting, and reproducible defect evidence.

kelinacowellqa.github.io