Key takeaways
- Retesting checks if a specific bug is fixed. Regression testing checks if that fix broke something else.
- Not every retest should become a permanent regression test. Promoting every fixed bug bloats your suite.
- On mobile, retesting on wrong device or OS version gives you a false pass.
A developer closes a bug ticket. A tester picks it up. What happens next is where most teams either catch side effects early or ship them to production.
The two types of testing that follow a bug fix are retesting and regression testing. They run in sequence, they answer different questions, and skipping either one creates a gap that shows up later as a user-reported incident.
What retesting actually involves
A tester finds a defect. They log it with steps to reproduce. A developer fixes underlying code. The tester then re-executes same test case, with same inputs, on same environment, to verify fix works.
That's retesting. It's narrow by design. You're not exploring. You're not checking adjacent features. You're running exact scenario that failed before and confirming it passes now.
The catch most articles skip: a retest that passes on one environment doesn't mean fix holds everywhere. If bug was "payment button unresponsive on Android 12," retesting on a Pixel 7 with Android 14 tells you nothing. The fix needs to be verified on OS version and device combination where it originally broke.
This is where retesting on mobile diverges from retesting on web. On web, environment is relatively stable (Chrome, Firefox, Safari). On mobile, environment is device itself, and there are thousands of combinations.
What regression testing actually involves
Regression testing checks whether recent changes (bug fixes, new features, config updates, dependency upgrades) have introduced new failures in parts of app that were previously working.
It's broader than retesting. A regression suite doesn't just re-run test case for fixed bug. It runs test cases across application's core flows to catch side effects developer didn't anticipate.
A real example: a developer fixes a date format bug in order history screen. The fix changes how app parses dates globally. Retesting confirms order history screen now shows correct format. Regression testing catches that same change broke date parsing in refund flow, because both screens share a utility function developer didn't realize was shared.
The economic reality of regression testing is that it grows with your codebase. Every new feature and every bug fix adds surface area that needs to be protected. Without automation, regression suites become unsustainable within a few months. A team with 500 regression test cases can't run them manually before every release.
Where teams actually get confused
The definitions are simple. The mistakes happen in execution.
Treating every retest as a regression test. A tester retests a fixed bug, it passes, and they add that test case to permanent regression suite. Do this 200 times and your regression suite is bloated with one-off verifications that don't protect against future regressions. Not every fixed bug represents a recurring risk. Some bugs are environmental flukes that won't resurface.
The filter should be: does this defect represent a pattern that could recur? If a date parsing bug broke because of a shared utility, yes, add it. If a button was misaligned because someone hard-coded a pixel value, probably not.
Running retests without running regression. The developer fixes bug. The tester retests and confirms it's fixed. Everyone moves on. Nobody checks whether fix introduced side effects. Two sprints later, a user reports that checkout is broken. The root cause traces back to "fix" that was retested but never regression-tested.
This happens most often when teams don't have automated regression suites. Manual regression is so slow that teams skip it under deadline pressure. The fix gets shipped, retest passes, and regression gap becomes a production incident.
Retesting on wrong environment. This is mobile-specific failure mode. A bug is found on a Samsung Galaxy A14 running Android 12 with One UI 4.1. The developer fixes it. The tester retests on an emulator running stock Android 14. The retest passes. But original bug was caused by Samsung's One UI rendering, which emulator doesn't replicate.
On web, this gap is smaller because browsers behave consistently. On mobile, gap between emulator and real device is where retesting fails silently.
When a retest should graduate into regression
This is decision most articles don't cover, and it's one that determines whether your regression suite stays useful or becomes a maintenance burden.
A retest should become a permanent regression test when:
- The defect was in shared code (a utility function, a base class, a common component). If one change broke it, another change can break it again.
- The defect was in a revenue-critical flow (login, checkout, payment, onboarding). The cost of this defect recurring is high enough to justify permanent coverage.
- The defect revealed a gap in your existing regression suite. If a checkout bug slipped through 300 regression tests, suite had a blind spot. The retest that caught it fills that gap.
A retest should be discarded when:
- The defect was a one-time configuration error (wrong API key in staging, a test database that wasn't seeded correctly).
- The defect was in code that's been entirely rewritten since fix. The original test case no longer maps to anything in codebase.
- The defect was cosmetic and environment-specific (a font rendering issue on one browser version that's since been deprecated).
Teams that don't make this distinction end up with regression suites of 2,000+ tests where half are stale. Those stale tests slow down CI, produce flaky results, and erode trust in suite.
The comparison at a glance
How two work together in a real sprint
Here's sequence that should happen after every bug fix. Most teams do steps 1 and 2. Few do step 3. Almost nobody does step 4.
- Developer pushes a fix and moves ticket to "Ready for QA."
- Tester retests specific defect. Same steps, same data, same device. If it fails, ticket goes back to developer. If it passes, move to step 3.
- The regression suite runs (either triggered manually or automatically on merge). If a new failure appears in an unrelated flow, fix caused a side effect. The developer gets a new ticket.
- The tester decides whether retest case should join permanent regression suite or be discarded. This is graduation decision from section above.
On mobile, step 2 has an extra layer. A fix for a bug found on a specific device should be retested on that device, not just on whatever device is closest. And regression suite in step 3 should run across real device matrix, not just on an emulator.
Drizz handles both sides of this. A tester can retest a specific flow by running a single plain-English test case on exact device where bug was found. Then same test case runs as part of regression suite across multiple devices and OS versions, without rewriting anything or maintaining separate scripts per device. Because Vision AI identifies elements visually rather than through selectors, same test works across device matrix without per-device adjustments.
FAQ
What is the difference between retesting and regression testing?
Retesting verifies that a specific reported defect has been fixed. Regression testing verifies that fix (or any other code change) hasn't broken existing functionality elsewhere in application. They answer different questions and should both happen after every bug fix.
Can retesting be automated?
It can, but it's often not worth investment. Retesting is a one-off verification of a specific fix. By time you automate test case, you could have manually verified it. The exception is when retest case gets promoted to regression suite, at which point automation pays off because it'll run repeatedly.
Should every retest become a regression test?
No. Only promote a retest to regression suite if defect was in shared code, a revenue-critical flow, or exposed a gap in existing coverage. One-time configuration errors, cosmetic bugs, and defects in rewritten code don't need permanent regression coverage. Adding every retest bloats suite and slows CI.
Which one should run first after a bug fix?
Retesting runs first. There's no point running regression on a fix that doesn't actually work. If retest fails, ticket goes back to developer. If retest passes, regression runs to check for side effects.
How does retesting differ on mobile vs web?
On the web, you retest in same browser where bug occurred. The environment is relatively stable. On mobile, the environment is the device itself: OS version, OEM skin, screen size, chipset. A retest on stock Android 14 doesn't validate a fix for a bug caused by Samsung's One UI on Android 12. You need to retest on the exact device and OS combination where defect was found.
