Retesting vs regression testing: the difference, with examples

The two terms get used as if they meant the same thing, and in a busy week they often collapse into one vague step: “test the new build”. That is how a fix gets marked done without anybody looking at it, or how a fix lands and quietly breaks the screen next to it. This guide explains both, shows where each one fits, and ends with a log you can copy to make sure neither gets skipped.

The short version

• Retesting asks one question about one bug: is it fixed? You repeat the steps from the bug report on a build that contains the fix and see whether the bug still happens.
• Regression testing asks a wider question about everything else: did this change break anything that was working? You run checks that passed before the change and confirm they still pass.

Retesting looks at what was broken. Regression testing looks at what was working. A build can pass one and fail the other.

What retesting is

Retesting, also called confirmation testing, is running a check again after a bug on it has been fixed, to confirm the fix works. It only exists because a bug was found: there is nothing to retest until something has failed.

A good retest has three properties:

• It follows the original report. The same steps, the same kind of account, the same data where it matters. If the bug was “the discount disappears when you go back from payment”, the retest goes back from payment, with a discount applied.
• It runs on a build that contains the fix. This sounds obvious and is the most common reason a retest means nothing. Check the version or build number before you start.
• It runs where the bug was reported. A bug raised on Android is retested on Android. A fix that works on iOS may never have reached the Android build at all.

A retest has two outcomes. If the bug is gone, the check passes on that platform. If it is still there, the check fails again and the bug goes back to whoever fixed it, with a note saying what you saw this time.

What regression testing is

A regression is something that used to work and no longer does. Regression testing is running checks that were passing, after a change, to catch those. The change might be a bug fix, a new feature, a library upgrade, a new version of iOS or Android, or a setting changed on the server.

Teams usually pick one of three sizes, depending on how big the change was:

• Selective (or partial). Only the checks near the change: the screen it is on, the features that share its code, and the different ways into it. Fine for a small fix where the developer can say what it touched.
• A fixed never-break set. A short list of journeys that run on every build whatever changed: sign up, sign in, password reset, the main thing the app is for, taking a payment. Six to ten checks.
• Full. Every check in the plan. Worth doing before a major release, after a large rebuild, or when nobody can say with confidence what a change touched.

Unlike a retest, the regression checks are written in advance and reused. They are simply the checks in your test plan that you already expect to pass.

Retesting vs regression testing, side by side

One bug, both kinds of testing

Here is how the two play out on a single, ordinary bug in a shop app.

1. The bug. A tester on Android removes the last item from the basket. The basket shows a total of 0.00 but the Checkout button is still there, and tapping it opens an empty payment screen. They raise it against the check “Removing the last item empties the basket”, on Android.
2. The fix. A developer changes how the basket works out whether it is empty, ships a new Android build and marks the bug fixed.
3. The retest. On an Android phone with the new build, the tester adds one item, opens the basket and removes it. The basket now says it is empty and the Checkout button is gone. The check passes on Android.
4. The regression checks. The fix touched the basket, so the tester also adds two items and removes one (the button must stay), applies a discount code, and pays for an order end to end. Then they run the short never-break set. If the developer changed code shared with web and iOS, those platforms get the basket checks too, because the fix could have changed them.

If the retest passes and a regression check fails, the bug is still fixed. The new failure is a new bug, raised on its own check, so the record shows both: the original is confirmed fixed, and something else broke.

When each one happens

• A bug is marked fixed: retest it, then run the checks around it.
• Before a release: retest every bug fixed since the last release, then run the never-break set, then the checks for whatever changed.
• After a hotfix: retest the bug the hotfix is for, and run the never-break set. A rushed fix is the one most likely to break something next to it.
• After a new OS version, browser version or library upgrade: nothing is fixed, so there is nothing to retest. This one is regression testing only.
• After a new feature: test the feature itself (that is neither retesting nor regression testing, just testing), then run the checks around it.

Why a fixed bug should not count as passed

The usual way retesting gets lost is simple. A check failed, the bug was fixed, and the check goes back to showing whatever it showed before the bug: passed. Nobody looked. The pass on screen was recorded on an earlier build, one without the fix in it, by someone who has not seen the new behaviour.

A fix is a claim, not a result. It might be right. It might fix the example in the report and miss the general case. It might be in the iOS build and not yet in the Android one. Until someone runs the check on the new build, nobody knows.

So the honest state for a fixed bug is neither passed nor failed. It is waiting for a retest. Whatever you use to track testing, it helps if that state exists and is visible, so a fix cannot drift back to passed on its own.

How to run them on web, iOS and Android

Most of a retest is the same everywhere. What differs is making sure you are really looking at the fixed build.

Web

• Confirm the fix is deployed where you are testing. If the app shows a version or commit anywhere, check it; if not, ask which environment has it.
• Reload without the cache, or use a private window. An old copy of the page can make a fixed bug look unfixed, and the reverse.
• Retest in the browser the bug was reported in. Layout and form bugs in particular are often specific to one browser or one screen width.
• For regression checks, cover at least one desktop and one phone-sized window.

iOS

• Install the build with the fix, usually through TestFlight, and check its build number in TestFlight or the app’s settings screen before you start.
• Use the same iOS version as the report where you can. Some bugs only appear on older versions or on a particular screen size.
• Install over the previous build rather than on a clean phone for at least one run. Some bugs only show up with data left behind by the last version.
• Simulators are fine for most retests, but not for push notifications, the camera or real payments. Bugs in those need a physical iPhone.

Android

• Install the fixed build from your testing track or as a direct install, and check the version code before you start.
• Android varies more by manufacturer than iOS does. If the bug was reported on one make of phone, retest on that make if you can, and say in the result which phone you used.
• For anything involving permissions, battery saving or the app being killed in the background, retest on a real device. Emulators are kinder than real phones.
• Run the regression checks on the oldest Android version you support as well as a recent one.

On every platform, write down what you retested on: the build, the device and the OS version. If the bug comes back later, that is the first thing anyone will ask.

For more on what tends to go wrong on phones specifically, see the mobile app testing checklist.

Putting both into one release pass

The order matters. Retest first, because a fix that did not work changes what else you need to check, and there is no point running a full regression pass on a build that is going to be replaced. Then run the checks around each fix, then the never-break set, then the checks for anything new in the release.

That is the shape of the release checklist: its first group is every fix from the last round, checked on the platform it was reported on, before anything else.

Agree up front what “done” means. A rule that works for most teams: every fix retested on every platform it affects, no failures in the never-break set, and no open bug on the work being released.

Manual or automated?

Regression testing is where automation earns its keep: the same stable checks, run on every build, with results a machine can judge. Retesting is usually done by hand, at least the first time, because a person following the original report can notice that the fix only half works, or works and looks wrong. Once a bug is confirmed fixed, its check is a good candidate to add to the regression set, automated or not, so the same bug cannot come back unnoticed.

qarunbook is for the manual side: it does not run automated tests. It is where the checks, the result on each platform, the bugs they turn up and the retests are kept.

Common mistakes

• Closing a bug because the developer said it was fixed. That is the claim. The retest is the result.
• Retesting on the wrong platform. The bug was on Android, the retest was done on the web because it was quicker, and the Android build never had the fix.
• Retesting on the old build. Check the build number first, every time.
• Retesting only the exact example. If the bug was with one discount code, try another. A fix that only works for the reported data is not a fix.
• Skipping regression checks because the fix was small. Small fixes in shared code break things far away from where they were made.
• Reopening the old bug for a new problem. If the original behaviour is fixed but something else broke, raise a new bug. Mixing the two makes it impossible to tell later what was fixed when.

How qarunbook handles the retest

qarunbook is built around the rule in this guide. Every bug is raised on the check that found it, for the platforms it affects, and that check reads as failed on those platforms while the bug is open.

• When the bug is marked fixed, the check does not go back to passed. It reads Needs retest on each platform the bug affects, because the pass it had was recorded on a build without the fix.
• It only leaves that state when somebody records a new result on that platform, after the fix. A new pass clears it. A new fail shows it failing again.
• The bug itself reads Confirmed fixed once a pass has been recorded after the fix on every platform it affects. Until then it stays in the retest list.
• The same applies when an AI assistant connected over MCP fixes the code and marks the bug fixed, or when a bug filed in Linear is moved to Done there. A fix can send a check for a retest. It cannot mark it passed.

The state is worked out from the results and their times rather than set by hand, so there is no “needs retest” flag for anyone to forget to clear.

The template

A retest log in the format qarunbook imports: a section for the fixes to confirm, a section for the checks around each fix, and a short never-break set. Copy it, replace the general fix checks with your own bugs if you prefer one row per bug, and keep the shape: a heading per section with its reference in brackets, one row per check, a column per platform.

# Retest log — build 43

## Fixes to confirm (FIX)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| FIX-01 | The reported bug no longer happens | The issue as it was reported: its steps, its platform, and a build that contains the fix | 1. Check the version or build number on the device matches the build with the fix. 2. Follow the steps from the original report exactly, with the same kind of account and data. | What the report said should have happened now happens. The original error, crash or wrong result does not appear. | | | |
| FIX-02 | The fix holds with different data | As above | 1. Repeat the original steps with a different account, item or value from the one in the report. | The same correct result. The fix is not tied to the one example in the report. | | | |
| FIX-03 | The fix reached every platform the issue affects | The issue lists more than one platform | 1. Repeat FIX-01 on each platform the issue lists, on a build of that platform that contains the fix. | Each platform shows the correct behaviour. A platform whose build has not shipped yet stays untested, not passed. | | | |
| FIX-04 | A fix that changed a message reads correctly | The fix changed text, an error or a label | 1. Trigger the message the fix changed. | The new wording appears in full, is not cut off, and makes sense to someone who has never seen the bug. | | | |

## Around each fix (NEAR)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| NEAR-01 | The rest of the screen still works | A build that contains the fix | 1. Open the screen where the fix was made. 2. Use every other button, field and link on it. | Everything else on the screen behaves the way it did in the last release. | | | |
| NEAR-02 | The other ways into the same feature | As above | 1. Reach the fixed feature from each other route: a notification, a link, the back button, a fresh launch. | The fix holds whichever way you arrive. | | | |
| NEAR-03 | Anything that shares the changed code | The developer's note on what the fix touched | 1. Run the checks for the other screens the developer named. | They pass as before. If nobody can say what the fix touched, run the never-break group in full. | | | |

## Never break (CORE)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| CORE-01 | Sign up | No account for the email you will use | 1. Create an account end to end. | The account is created, the verification email arrives, and the app opens signed in. | | | |
| CORE-02 | Sign in and sign out | An existing account | 1. Sign in. 2. Sign out. | Both work. After signing out, the back button does not show signed-in screens. | | | |
| CORE-03 | Reset a password | An existing account whose inbox you can open | 1. Run the reset flow to a new password. 2. Sign in with it. | The new password works and the old one does not. | | | |
| CORE-04 | The one thing the app is for | Signed in | 1. Complete the main journey end to end. | It completes with the result a customer would expect. | | | |
| CORE-05 | Take a payment | Signed in. A test card that will succeed | 1. Pay for something. | The payment succeeds once, the receipt matches the total, and nothing is charged twice. | | | |
| CORE-06 | Update over the previous version | The previous release installed and signed in | 1. Install this build over it. 2. Open the app. | Still signed in, data intact, and no second onboarding. | N/A | | |

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

There are more templates on the templates page, including the full release pass. If you are writing the checks themselves, start with how to write test cases.

Questions people ask

Is retesting part of regression testing?

No. They often happen in the same session, but they answer different questions. Retesting checks a failure has gone away; regression testing checks that passes have stayed. Most teams retest first and run regression checks straight after.

Is confirmation testing the same as retesting?

Yes. Confirmation testing is the more formal name for the same thing.

Can you run them at the same time?

With more than one tester, yes: one person retests the fixes while another runs the never-break set. Just do not count the regression results as final until every retest has passed, since a failed retest usually means another build.

What if the retest passes on one platform and fails on another?

Record each separately. The bug is fixed on one and not the other, and it should stay waiting on the platform where it failed until a build there passes.