Guide · updated 15 October 2026

Regression testing checklist

Regression testing answers one question: did this change break something that used to work? You don't need to retest the whole app to answer it. Four groups of checks catch most regressions.

Retesting checks that a fix worked. Regression testing checks that nothing else broke because of it. They are different jobs, and the second one is the one teams skip when a release is late. (The difference is spelled out in retesting vs regression testing.)

1. Around the change

Most regressions sit next to the change, not inside it. Use the rest of the screen that changed, every other screen that reads the same data, and a few screens that share the component you touched. Then open a record created before this build: old data is where a new field or a changed rule usually fails.

2. The paths that must never break

Keep a short fixed list that runs after every change, however small: sign up, sign in and out, password reset, the one journey the app exists for, and taking a payment. Five or six checks. If one fails, nothing else about the release matters.

3. Bugs that came back before

Bugs come back. Every issue fixed in the last few releases earns a place on the list until it has stayed fixed for a while. Check each one on the platform it was reported on, and for fixes in shared code, on every platform, because a fix that works on web may never have reached iOS.

4. The device and the network

The last group catches the regressions that never show on a developer's machine: upgrading over the previous build while signed in, a slow or dropped connection, the smallest supported screen, and the largest text size.

The checklist

regression-testing-checklist.md

Import it

# Regression testing checklist

## Around the change (NEAR)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| NEAR-01 | The rest of the changed screen still works | The build with the change | 1. Open the screen that changed. 2. Use every other control on it. | Every other control behaves exactly as in the last release. | | | |
| NEAR-02 | Screens that read the same data | A record the change touches | 1. Open every screen that shows this record. | Each one shows the same, correct values. | | | |
| NEAR-03 | Shared components still look right | The change touched a shared component | 1. Open three other screens that use it. | Layout, text and taps are unchanged there. | | | |
| NEAR-04 | Old data still opens | A record created before this build | 1. Open it. 2. Edit and save it. | It opens, edits and saves without errors. | | | |

## Paths that must never break (CORE)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| CORE-01 | Sign up | No account | 1. Create an account end to end. | Account created, verification arrives, app opens. | | | |
| CORE-02 | Sign in, then sign out | An existing account | 1. Sign in. 2. Sign out. | Both work; signing out clears the session. | | | |
| CORE-03 | Reset a password | An existing account | 1. Request a reset. 2. Set a new password. | The new password works and the old one does not. | | | |
| CORE-04 | The main journey | Signed in | 1. Complete the one thing the app is for. | It completes with the result the user expects. | | | |
| CORE-05 | Take a payment | A test card | 1. Pay for something. | Payment succeeds once, and the receipt matches. | | | |

## Bugs that came back before (BACK)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| BACK-01 | Every bug fixed in the last three releases | The list of fixed issues | 1. Reproduce each original report step by step. | None of them happens again, on the platform it was reported on. | | | |
| BACK-02 | Fixes in shared code, on every platform | A fix merged in code more than one platform uses | 1. Repeat the original steps on each platform. | Fixed everywhere, not just where it was reported. | | | |

## The device and the network (ENV)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| ENV-01 | Upgrade over the previous build | Previous version installed, signed in | 1. Install this build over it. | Still signed in, data intact, no new onboarding. | N/A | | |
| ENV-02 | A slow or dropped connection | Network throttled, then cut | 1. Repeat the main journey. | Clear messages, nothing lost, it recovers when the network returns. | | | |
| ENV-03 | The smallest supported screen | Smallest phone or a narrow browser | 1. Open the changed screens. | Nothing overlaps or is cut off. | | | |
| ENV-04 | Large text | System text size at maximum | 1. Open the changed screens. | Text is readable and buttons can still be tapped. | | | |

Or take the file: Markdown·CSV·Excel·no email, no sign-up.

Keep it from growing forever

A regression list that only grows stops being run. Each release, drop the old bugs that have stayed fixed for three releases, and keep the never-break group at six checks or fewer. A list people actually finish beats a complete one nobody does.

Run it on every platform without a second spreadsheet

Import this checklist into qarunbook and each check gets a result per platform, so a check can pass on web and fail on iOS on the same row. When a bug is fixed, its check goes back for a retest on the platforms the fix changed, so nobody retests the wrong platform or closes a bug that is only half fixed.