Forem: Kelina Cowell

Regression testing workflow: the risk first checks that keep releases stable

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

Portfolio version (canonical, with full context and styling):

https://kelinacowellqa.github.io/Manual-QA-Portfolio-Kelina-Cowell/articles/regression-testing.html

TL;DR

Workflow shown: risk first regression scoping → golden path baseline → targeted probes → evidence backed results.
Example context: Sworn on PC Game Pass (Windows) used only as a real world backing example.
Build context: tested on the PC Game Pass build 1.01.0.1039.
Scope driver: public SteamDB patch notes used as an external change signal (no platform parity assumed).
Outputs: a regression matrix with line by line outcomes, session timestamps, and bug tickets with evidence.

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

Regression testing scope: what I verified and why

This article is grounded in a self directed portfolio regression pass on Sworn using the PC Game Pass (Windows) build 1.01.0.1039, run in a one week solo timebox.

Scope was change driven and risk based: golden path stability (launch → play → quit → relaunch), save and continue integrity, core menus, audio sanity, input handover, plus side effect probes suggested by upstream patch notes.

No Steam and Game Pass parity claim is made.

What regression testing is (in practice)

For me, regression testing is simple: after change, does existing behaviour still hold.

Not “re test everything”, and not “run a checklist because that’s what we do”.

A regression pass is selective by design. Coverage is driven by risk:
what is most likely to have been impacted, what is most expensive if broken, and what must remain stable for the build to be trusted.

Regression testing outputs: pass and fail results with evidence

Clear outcomes: pass or fail, backed by evidence and repeatable verification. Not opinions. Not vibes.

Golden path smoke baseline for regression testing

I start every regression cycle with a repeatable golden path smoke because it prevents wasted time. If the baseline is unstable, deeper testing is noise.

In this Sworn pass, the baseline line was BL-SMOKE-01:
cold launch → main menu → gameplay → quit to desktop → relaunch → main menu.

I also include a quick sanity listen for audio cutouts during this flow.

Some systems absolutely cannot break. Those are the ones you want to verify on every build before spending time on deeper testing.

Conrad Bettmann, QA Manager (Rovio Entertainment)

Why baseline stability matters in regression testing

The golden path includes the most common player actions (launch, play, quit, resume). If those are unstable, you get cascading failures that masquerade as unrelated defects.

Regression testing scope: change signals and risk

For this project I used SteamDB patch notes as an external oracle: SWORN 1.0 Patch #3 (v1.0.3.1111), 13 Nov 2025.

That does not mean I assumed those changes were present on PC Game Pass.

Instead, I used the patch notes as a change signal to decide where to probe for side effects on the Game Pass build. This is useful when you have no internal access, no studio data, and no changelog for your platform.

Knowing what changed and where helps you focus regression on affected areas, rather than running very wide checks that probably won’t find anything valuable. It’s usually best to mix multiple oracles instead of relying on one source.

Conrad Bettmann, QA Manager (Rovio Entertainment)

Regression outcomes: pass vs not applicable (with evidence)

SteamDB notes mention a music cutting out fix, so I ran an audio runtime probe (STEA-103-MUSIC) and verified music continuity across combat, pause and unpause, and a level load (pass).

SteamDB also mentions a Dialogue Volume slider. On the Game Pass build that control was not present, so the check was recorded as not applicable with evidence of absence (STEA-103-AVOL).

How my regression matrix is structured

My Regression Matrix lines are written to be auditable. Each line includes a direct check, a side effect check, a clear outcome, and an evidence link.

That keeps results reviewable and prevents “I think it’s fine” reporting.

Example matrix lines:

Baseline smoke: BL-SMOKE-01
Settings persistence: BL-SET-01
Save and Continue integrity: BL-SAVE-01
Post death flow sanity: BL-DEATH-01
Audio runtime continuity probe: STEA-103-MUSIC
Audio settings presence check: STEA-103-AVOL
Codex and UI navigation sanity: STEA-103-CODEX
Input handover plus hot plug: BL-IO-01
Alt Tab sanity: BL-ALT-01
Enhancement spend plus ownership persistence: BL-ECON-01

Save and Continue regression testing: anchors, not vibes

Save and Continue flows are a classic regression risk area because failures can look intermittent. To reduce ambiguity, I verify using anchors.

In this pass (BL-SAVE-01), I anchored:
room splash name (Wirral Forest), health bucket (60/60), weapon type (sword), and the start of objective text.

I then verified those anchors after menu Continue and after a full relaunch.

Outcome: pass, anchors matched throughout (session S2).

Why anchors make regression results repeatable

“Continue worked” is not useful if someone else cannot verify what you resumed into. Anchors turn “seems fine” into a repeatable verification result.

QA evidence for regression testing: what I capture and why

For regression, evidence matters for passes as much as failures. A pass is still a claim.

Video clips: show input, timing, and outcome together (ideal for flow and audio checks).
Screenshots: support UI state, menu presence and absence, and bug clarity.
Session timestamps: keep verification reviewable without scrubbing long recordings.
Environment notes: platform, build, input devices, cloud saves enabled.

If the evidence cannot answer what was done, what happened, and what should have happened, it is not evidence.

Regression testing examples from the Sworn pass

Example regression bug: Defeat overlay blocks the Stats screen (SWOR-6)

Bug: [PC][UI][Flow] Defeat overlay blocks Stats; Continue starts a new run (SWOR-6)
Expectation: after Defeat, pressing Continue reveals the full Stats screen in the foreground and waits for player confirmation.
Actual: Defeat stays in the foreground, Stats renders underneath with a loading icon, then a new run starts automatically. Outcome: you cannot review Stats.
Repro rate: 3/3, observed during progression verification (S2) and reconfirmed in a dedicated re test (S6).

Patch note probe example: music continuity check (STEA-103-MUSIC)

SteamDB notes mention a fix for music cutting out, so I ran STEA-103-MUSIC:
10 minutes runtime with combat transitions, plus pause and unpause and a level load.

Outcome: pass, music stayed continuous across those transitions (S3).

Evidence backed not applicable example: missing Dialogue Volume slider (STEA-103-AVOL)

SteamDB notes mention a Dialogue Volume slider, but on the Game Pass build the Audio menu only showed Master, Music, and SFX.

Outcome: not applicable with evidence of absence (STEA-103-AVOL, S4). This avoids inventing parity and keeps the matrix honest.

Accessibility issues logged as a known cluster (no new build to re test)

On Day 0 (S0), I captured onboarding accessibility issues as a known cluster (B-A11Y-01: SWOR-1, SWOR-2, SWOR-3, SWOR-4). Because there was no newer build during the week, regression re test was not applicable until a new build exists. This is logged explicitly rather than implied.

Results snapshot (for transparency)

In this backing pass, the matrix recorded: 8 pass, 1 fail, 1 not applicable, plus 1 known accessibility cluster captured on Day 0 with no newer build available for re test.

Counts are included here for context, not as the focus of the article.

Regression testing takeaways (risk, evidence, and verification)

Regression testing is change driven verification, not “re test everything”.
A repeatable golden path baseline stops you wasting time on an unstable build.
External patch notes can be used as a risk signal without assuming platform parity.
Anchors make progression and resume verification credible and repeatable.
Not applicable is a valid outcome if it is evidenced, not hand waved.
Pass results deserve evidence too, because they are still claims.

Regression testing FAQ (manual QA)

Is regression testing just re testing old bugs?

No. Regression testing verifies that existing behaviour still works after change. It covers previously working systems, whether or not bugs were ever logged against them.

Do you need to re test everything in regression?

No. Effective regression testing is selective. Scope is driven by change and risk, not by feature count.

How do you scope regression without internal patch notes?

By using external change signals such as public patch notes, previous builds, and observed behaviour as oracles, without assuming platform parity.

What’s the difference between regression and exploratory testing?

Regression testing verifies known behaviour after change. Exploratory testing searches for unknown risk and emergent failure modes. They complement each other but answer different questions.

Is a pass result meaningful in regression testing?

Yes. A pass is still a claim. That’s why regression passes should be supported with evidence, not just a checkbox.

When is not applicable a valid regression outcome?

When a feature is not present on the build under test and that absence is confirmed with evidence. Logging this explicitly is more honest than assuming parity or skipping the check silently.

Evidence and case study links

Sworn regression case study (full artefacts and evidence):

https://kelinacowellqa.github.io/Manual-QA-Portfolio-Kelina-Cowell/projects/sworn/
SteamDB patch notes used as external oracle (SWORN 1.0 Patch #3, v1.0.3.1111):

https://steamdb.info/patchnotes/20786520/

This dev.to post stays focused on the regression workflow. The case study links out to the workbook tabs (Regression Matrix, Sessions Log, Bug Log) and evidence clips.

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

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

Portfolio version (canonical, with full context and styling):

https://kelinacowellqa.github.io/Manual-QA-Portfolio-Kelina-Cowell/articles/exploratory-testing.html

TL;DR

What it is: risk-driven exploratory sessions where design, execution, and analysis happen together.
Platform context: mobile (Android), where interruptions and device state changes are normal.
Timebox: short focused sessions, not long wandering playthroughs.
Approach: charters, controlled variation, observation-led decisions.
Outputs: defects and observations that explain behaviour, with enough context to reproduce.

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

About this article

Exploratory testing is often summarised as “testing without scripts”. In real mobile QA work, that description is incomplete.

This article explains exploratory testing on mobile as it is actually applied in a practical workflow: session structure, risk focus, interruptions and recovery, and how this approach consistently finds issues that scripted checks often miss.

Examples are drawn from a real Android mobile game pass, but the focus here is the method, not the case study.

What exploratory testing actually means

In practice, exploratory testing is a way of working where test design, execution, and analysis happen together.

You are not following a pre-written script. You are observing behaviour and choosing the next action based on risk, evidence, and what the product is doing right now.

That does not mean “random testing”. It means structured freedom: you keep a clear intent, and you keep your changes controlled so outcomes remain interpretable.

Why exploratory testing matters on mobile

Mobile products rarely fail under perfect conditions. They fail when something changes unexpectedly. On Android especially, many failure modes are contextual and lifecycle-driven.

Alarms, calls, and notifications interrupt active flows.
Apps are backgrounded and resumed repeatedly.
Network quality changes during critical moments (login, purchase, reward claim).
UI must remain usable on small screens and unusual aspect ratios.

Applied insight: For mobile exploration, compare performance across devices where possible and probe interruptions: lock screen, phone calls, network drops, switching Wi-Fi/data, rotation, and kill/restart recovery.

Radu Posoi, Founder, AlkoTech Labs (ex Ubisoft QA Lead)

Exploratory sessions target these risks directly instead of assuming a clean uninterrupted journey.

Exploratory testing workflow in practice

Exploratory test charters, not scripts

Sessions start with a charter: a short statement of intent.

For example, “Explore reward claim behaviour under interruptions” or “Explore recovery after network loss”.

The charter defines focus, not steps.

Timeboxed exploratory testing sessions

Exploratory testing works best in short sessions. Timeboxing forces prioritisation and prevents unfocused wandering.

Typical sessions range from 20 to 45 minutes.

Applied insight: Before you go deep, verify the basics first. A short daily smoke test protects the golden path, so deeper exploratory work is not wasted rediscovering obvious breakage.

Nathan Glatus, ex Senior QA / Game Integrity Analyst (Fortnite, ex Epic Games)

Controlled variation: one variable at a time

Rather than changing everything at once, one variable is altered at a time: lock state, network type, lifecycle state.

This keeps results interpretable and defects reproducible.

Exploratory testing session checklist (charter, timebox, evidence)

Charter chosen (risk and focus)
Timebox set (20 to 45 mins)
Variables defined (one at a time)
Notes captured live
Evidence captured when it happens
Bug report drafted while context is fresh

Common mobile bugs found with exploratory testing

Exploratory testing is effective at surfacing issues that are low-frequency but high-impact, especially on mobile.

Soft locks where the UI appears responsive but progression is blocked.
State inconsistencies after backgrounding or relaunch.
Audio or visual desynchronisation after OS-level events.
UI scaling or readability problems that only appear in specific contexts.

Android exploratory testing example: reward claim soft lock

Scenario: reward claim flow under interruptions (Android).

During an exploratory session, repeatedly backgrounding and resuming the app while a reward flow was mid-animation triggered a soft lock: the UI stayed visible, but the claim state never completed, blocking progression.

This did not appear during clean uninterrupted smoke testing because the trigger was lifecycle timing and state recovery.

Why this matters: it is normal user behaviour on mobile, not a rare edge case. Exploratory sessions hit it because they are designed to.

Bug reporting for exploratory testing: notes and evidence

Because exploratory testing is adaptive, notes and evidence matter more than in scripted runs. Findings must be supported with enough context to reproduce and diagnose.

Applied insight: High impact exploratory bugs live or die by their evidence. Capture context (client and device state), include frequency (for example 3/3 or 10/13), and attach a clear repro so the issue is actionable.

Nathan Glatus, ex Senior QA / Game Integrity Analyst (Fortnite, ex Epic Games)

Screen recordings captured during the session, not recreated later.
Notes that include context, not just actions (device state, network, lifecycle transitions).
Bug reports that clearly separate expected behaviour from actual behaviour.

The goal is to make exploratory findings actionable, not anecdotal.

Exploratory testing skills shown in this mobile pass

Risk-based testing decisions
Test charter creation and execution
Defect analysis and clear bug reporting
Reproduction step clarity under variable conditions
Evidence-led communication
Mobile UI and interaction awareness
Device and network variation testing

Key takeaways for mobile QA

Exploratory testing is structured, not random.
Mobile risk is contextual, not just functional.
Interruptions and recovery deserve dedicated exploration.
Good notes and evidence make exploratory work credible and actionable.

Exploratory testing FAQ (mobile QA)

How do you stop exploratory testing becoming random wandering?

By using a clear charter, a strict timebox, and controlled variation. If you can’t explain what you were trying to learn in that session, the charter is too vague.

What do you write down during an exploratory session?

The variables that matter for reproduction: device state, network, lifecycle transitions, and what changed between attempts. Notes should capture context, not just button presses.

How do you reproduce a bug found through exploration?

First, reduce the scenario to the smallest set of steps that still triggers the issue. Then rerun it while changing one variable at a time until the trigger conditions are clear.

What makes mobile exploratory testing different from PC or console?

Mobile failure modes are often lifecycle and OS-driven: backgrounding, notifications, lock/unlock, network switching, permissions, battery and performance constraints. Normal user behaviour creates timing and recovery issues that clean runs will miss.

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.to post stays focused on the workflow. The case study links out to the workbook structure, runs, and evidence.

Functional testing: the boring basics that catch real bugs

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

Portfolio version (canonical, with full context and styling):

https://kelinacowellqa.github.io/Manual-QA-Portfolio-Kelina-Cowell/articles/functional-testing.html

TL;DR

What it is: a functional testing workflow for timeboxed solo passes.
Backing project: Battletoads on PC (Game Pass), one-week pass (27 Oct to 1 Nov 2025).
Approach: validate start-to-control and Pause/Resume first, then expand where risk appears (often input and focus).
Outputs: pass/fail outcomes, reproducible defect reports, and short evidence recordings supporting each finding.

Functional testing workflow used during a one-week Battletoads (PC) pass.

Functional testing workflow context and scope

This article is grounded in a self-directed portfolio pass on Battletoads (PC, Game Pass), build 1.1F.42718, run in a one-week timebox.

Test focus was core functional flows and mixed input ownership (controller plus keyboard), with short evidence clips captured for reproducibility.

What functional testing is (in practice)

For me, functional testing is simple: does the product do what it claims to do, end-to-end, without excuses or interpretation?

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

The mistake is treating functional testing as “easy” and therefore less valuable. It is the foundation. If the foundation is cracked, everything built on top of it fails in more complicated ways.

Functional testing outputs: pass/fail results with evidence

Clear outcomes: pass or fail, backed by evidence and reproducible steps. Not vibes. Not opinions.

The two flows I verify first

1) Start to first control

The first minute determines whether the product feels broken. If “New Game” does not reliably get you playing, nothing else matters.

In Battletoads, I validate this from Title into Level 1 and through the first arena transition before expanding scope.

2) Pause and Resume

Pause stresses state, focus, input context, UI navigation and overlays. If Pause is unstable, you get a stream of defects that look random but are not.

In Battletoads (PC), this surfaced early as keyboard and controller routing issues around Pause and Join In.

Input ownership testing: controller and keyboard hand-off

Mixed input is a feature, not an edge case. When a controller is connected and a keyboard is used, behaviour must remain predictable.

Pause must open consistently.
Navigation must respect the active input method.
Confirm and back must not silently stop responding.
Hand-off must not route to the wrong UI or disable input.

I treat keyboard and controller hand-off as a dedicated test area because it produces high-impact, easily reproducible defects. In this Battletoads pass, mixed input could misroute actions (for example, Resume opening Join In) and temporarily break controller response.

Common pattern: mixed input causes menu focus bugs

Controller connected + keyboard input + menu open = focus bugs. Easy to reproduce. Easy to prove. Easy to fix once isolated.

Bug evidence: what I capture and why

I favour short video clips (10 to 30 seconds) and only use screenshots when they add clarity. The goal is to make the defect obvious without forcing someone to scrub a long recording.

Video: shows timing, input, and incorrect outcome together.
Screenshot: supports UI state, text, or configuration.
Environment: platform, build/version, input device, display mode.

If the evidence cannot answer what was pressed, what happened, and what should have happened, it is not evidence.

How I timebox a one-week pass

Day 1: Smoke testing and baseline flow validation.
Days 2 to 4: Execute runs, expand where risk appears, log defects immediately.
Days 5 to 6: Retest, tighten repro steps, confirm consistency.
Day 7: Summarise outcomes and document learnings.

Practical note: I start each session with a short baseline loop (load, gain control, Pause, resume) before deeper checks. It catches obvious breakage early and prevents wasted time.

Testing oracles used for functional verification

In-game UI and outcomes: observable behaviour of core flows (control, progression, Pause/Resume).
Controls menu bindings: used as an oracle for expected key behaviour (for example, Esc and Enter bindings).
Consistency across repeated runs: behaviour confirmed via reruns to rule out one-off variance.

Examples from the Battletoads functional pass

Example bug pattern: mixed input misroutes Pause and overlays

With a controller connected on PC, Pause opened and closed reliably via controller Start. Keyboard interaction on Pause could be ignored or misrouted into Join In, and in one observed case the controller became unresponsive until the overlay was closed.

Short evidence clips were captured to show input, timing, and outcome together.

Micro-charter: mixed input ownership around Pause and overlays

Charter: Mixed input ownership around Pause and overlays (controller plus keyboard).
Goal: Confirm predictable focus, navigation, and confirm/back actions under common PC setups.

Functional testing takeaways (flows, input, evidence)

Functional testing finds high-impact defects early because it targets the systems everything else relies on.
Pause and overlays are reliable bug generators because they stress state and input routing.
On PC, mixed input should be treated as a primary scenario, not an edge case.
Short evidence clips reduce repro ambiguity and speed up triage.
Repeating the same steps is how “random” issues become diagnosable patterns.

Functional testing FAQ (manual QA)

Is functional testing just basic or beginner testing?

No. Functional testing validates the core systems everything else depends on. When it’s done poorly, teams chase “random” bugs that are actually foundational failures.

Does functional testing only check happy paths?

No. It starts with happy paths, but expands wherever risk appears. Input ownership, Pause/Resume, and state transitions are common failure points.

How is functional testing different from regression testing?

Functional testing validates expected behaviour end-to-end. Regression testing verifies that previously working behaviour still holds after change. They overlap, but they answer different questions.

Is functional testing still relevant if automation exists?

Yes. Automation relies on a correct understanding of expected behaviour. Functional testing establishes that baseline and finds issues automation often misses.

What makes a functional bug report “good”?

Clear steps, a clear expected result, a clear actual result, and short evidence that shows input, timing, and outcome together.

Evidence and case study links

Battletoads functional case study (full artefacts and evidence):

https://kelinacowellqa.github.io/Manual-QA-Portfolio-Kelina-Cowell/projects/battletoads/
QA Chronicles Issue 1: Battletoads:

https://kelinacowellqa.github.io/QA-Chronicles-Kelina-Cowell/issues/issue-01-battletoads.html

This dev.to post stays focused on the workflow. The case study links out to the workbook structure, runs, and evidence.