What Is Retesting? How It Differs From Regression Testing

You merged the fix twenty minutes ago. The pipeline is queued, and someone, maybe you, has to decide what runs before this build ships: just the case that failed, or the whole suite. What follows is what a retest is, how it differs from regression testing, and what order to run them in.

For the three-way trigger comparison one level up, see smoke vs sanity vs regression testing.

What retesting actually is

Retesting is narrower than most glossaries let on. A test case fails, someone diagnoses the defect, a fix ships. Retesting reruns that exact case against the new build to confirm the one specific defect is gone, nothing else about the case changes. ISTQB's Foundation Level syllabus calls this confirmation testing, defined as confirming that an original defect has been successfully fixed by executing the tests that previously failed because of it.

A retest reuses five things from the original failure: the original steps, run in the same sequence that produced the failure; the original data, the same input values rather than a new dataset that might dodge the bug; the original environment, the same browser, build target or account state the defect was reported in; the recorded expected result, what "correct" looked like before the fix; and the defect ID it closes, since retesting exists to close one named defect, not to explore.

A retest inherits all five inputs from the original failure. A fresh case invents every one of them.

Whoever owns the fix usually runs the retest. It's finished the moment the actual result matches the recorded expected result, closing the defect.

One claim worth correcting: retesting is sometimes called impossible to automate, on the assumption that a failing case only exists as a bug report someone re-types from memory. Once the case is a stored, replayable artifact, its steps, data and environment captured once, running it again on demand is no different from any other automated test.

What a retest looks like in practice

Here's a retest worked end to end. The defect: a loyalty discount code stops applying at checkout on orders over $50.

Field	Value
Defect ID	BUG-482
Steps	Add $60 item, apply code LOYAL10, view total
Original expected	Total shows $54.00, 10% off applied
Original actual	Total shows $60.00, code ignored
Retest actual (after fix)	Total shows $54.00, discount applied
Exit condition	Actual equals expected, BUG-482 closes

The retest here is exactly the case above, run again, nothing added. It skips the tax line, the shipping estimate and any other discount code, because none of those are what BUG-482 was about. That's not a gap, it's the scope doing its job: a retest that wandered into adjacent checks would just be a small regression pass wearing a retest's name.

Retesting vs regression testing

With a retest defined concretely, here's the distinction that sends most people searching in the first place.

	Retesting	Regression Testing
Trigger	A specific fix just landed	Any change with unknown blast radius
Scope	One case, the one that failed	Most or all of the suite
Who decides scope	Fixed already, by the defect ID	A person or tool picks the surface
Is it planned	Yes, before the fix ships	Often not fully, scope grows with the change
When it's finished	Actual matches recorded expected	The chosen suite passes clean
A failure means	The fix didn't work	Something unrelated broke

The one-line version: retesting is targeted and planned, because you already know exactly what you fixed; regression testing is broad, and its scope is often not fully planned, because you don't know everything the fix touched. The suite-strategy questions, size, selection, avoiding rot, are answered at regression testing, with automation covered at the automated regression testing guide. A third gate, sanity testing, sits between the two when a fix needs checking around the change without the full regression surface.

Retesting reruns the single case that failed; regression testing sweeps the rest of the suite.

When to retest vs run a regression test, and in what order

Run the retest first. It's the cheaper of the two, one case rather than a whole suite, and it acts as a gate: if the fix didn't land, everything downstream is wasted effort.

The retest is the gate. A failed retest short-circuits the run and sends the fix back before the suite spends any time.

That ordering assumes the regression suite has a real cost worth avoiding, in time or flaky reruns, which is what the classical advice is built on. It weakens once the suite behind both runs is generated rather than hand-picked: if standing up either run is cheap, retesting and the regression pass can execute in parallel against the same build. The retest still gates the merge, a failed retest still means send the fix back first. Where this sits inside the release flow as a whole is covered at the release management process.

How Autonoma handles both after a fix

Everything above assumes regression is a curated, hand-maintained suite: a list someone wrote once and now has to keep working every time the UI shifts underneath it. That constraint is exactly what pushes teams toward running only the retest and skipping the broader pass, or running it so rarely it stops catching anything. When the checks instead come from the codebase and heal on their own instead of needing manual repair, the gate stops being something you maintain and becomes a signal you regenerate, and the scarce work moves to reviewing what that signal surfaces.

We built Autonoma's agents to read a connected codebase directly, rather than work from a hand-written list, and the tests they generate run against a live preview of the application itself. That architecture changes what retesting and regression testing actually are here: two different reads of the same generated suite, not two runs competing for the same scarce maintenance budget. The retest is the one stored case that originally failed, replayed against the new build. The regression pass is the rest of that same generated suite, run against the same build. Neither is hand-curated, so neither has to be rationed. The Diffs Agent is what makes the second read worth looking at: instead of a wall of green or a wall of red, it surfaces what changed between this run and the last one, so reviewing a regression pass becomes reading a diff instead of re-verifying everything from zero.

Autonoma generates one suite and reads it twice: the retest replays the stored case, the regression pass covers the rest.

Mapped onto the sections above: the worked BUG-482 retest is exactly the kind of stored case Autonoma can replay on demand against a new build. The comparison table's "who decides scope" row is what the Diffs Agent answers on the regression side, naming what changed rather than leaving scope to guesswork. And the ordering from the previous section still holds, retest first, except both runs are now cheap enough that skipping the regression pass to save time is rarely worth it.

When retesting is not enough

A passing retest tells you one thing, precisely: the defect you filed is gone under the conditions you tested it in. It does not tell you the fix was the right fix. A discount code that now applies correctly at checkout might still be the wrong discount, applying to a $50 order when the intended threshold was $75, and a retest built around the original bug report will pass cleanly against that mistake, because passing was never checking for it.

That judgment call, whether the fix solves the right problem rather than just the reported symptom, stays a human one. So does exploratory follow-up around a defect that's technically fixed: poking at the area a few different ways a bug report never specified, because a person suspects the fix is narrower than it looks. Retesting closes the ticket. It was never meant to answer whether the ticket described the right problem in the first place, and that's true whether the underlying suite was hand-written or generated from the codebase: no suite, however it was built, can tell you the ticket itself was pointed at the right problem.

None of this changes because the underlying checks are generated instead of hand-written. What changes is which parts are still worth a person's attention. Retesting and regression testing were always two different questions, one narrow and one broad, and conflating them is how teams end up either skipping the broad pass to save time or running it so rarely it stops meaning anything. Connect a codebase to Autonoma and both reads happen on every fix without someone deciding in advance which one gets skipped this week. The retest closes the ticket, the regression pass confirms nothing else moved, and neither was ever going to tell you the ticket was the right one to file. The fix still needs a human to judge that, and that's fine.

Frequently Asked Questions