Regression vs retesting: the difference that bites in practice

These two get muddled constantly, usually with expensive results. A developer fixes a bug, QA confirms the bug is gone, everyone ships — and a week later a different feature is broken because nobody checked the blast radius of the change. Retesting and regression are both things you do after a change, but they're aimed at different targets, and skipping one because you did the other is how regressions escape.

What each one actually checks

Retesting (sometimes "confirmation testing") is narrow and targeted: you re-run the exact scenario that failed, on the new build, to confirm the reported defect is genuinely fixed. It's deliberate, it's scoped to the bug, and it follows the original reproduction steps — plus a couple of close variations to make sure the fix isn't suspiciously specific. You always know which tests to run, because they're the ones that just failed.

Regression testing is broad and preventive: you re-run a wider set of previously passing tests to confirm the change didn't break something that was already working. It's not aimed at the fix — it's aimed at everything the fix could have rippled into: shared components, the same data model, the surrounding flow. You don't know in advance which test will catch the problem, which is the whole reason you run a set rather than a single case.

The decision rule

You don't choose between them — a code change usually needs both, in order. First retest: prove the specific thing is fixed (no point regression-testing around a fix that didn't take). Then regression: prove nothing nearby broke. The real decisions are about scope:

• Retest scope is set by the bug: the failing scenario plus its obvious variations. Small and precise.
• Regression scope is set by risk and blast radius: what does this change touch, and what's most costly if it breaks? You can't re-run everything every time, so you select — ideally with risk in mind, not just coverage, and ideally without burning two days on it.

Regression vs retesting: getting both right

• After a bug fix → retest the exact failing scenario on the new build (don't assume)
• Retest a couple of close variations, not just the literal reproduction steps
• After any code change → regression the areas it could ripple into, even if the fix retested clean
• Scope regression by blast radius and risk, not by re-running the whole suite blindly
• Automate the stable regression set so retesting a fix doesn't crowd out checking for side effects
• A retest that passes is not a release signal on its own — it says the fix works, nothing about collateral damage
• Track which regressions a change actually caused; it tells you where your blast-radius guesses are wrong

Why the confusion is expensive

The failure is almost always the same shape: the team retests (the bug is gone!) and calls it done, skipping regression because "we only changed one thing." But one change to shared code is exactly what produces a regression elsewhere, and the green retest gives false confidence that masks it. The opposite mistake is rarer but real — running a big regression pass and never actually confirming the original fix, so you ship a "fixed" build where the bug is still there. Keep the two jobs separate in your head: retesting answers did we fix it?, regression answers did we break anything getting there? Both questions need an answer before the build is trustworthy.