Retest Is Not Regression

A tester closed a requirement. A developer then changed something in the same area.

What happened next was reported as "it's been tested." Nobody in the room could say which of the two things it actually was — and they are not the same thing.

The Two Definitions, Which Take Ten Seconds

Retest is re-running the specific test that found the defect, on the build that contains the fix, to confirm the defect is gone.

Regression is running tests that already passed, to prove they still pass after the change.

One looks at the thing that was broken. The other looks at everything that was not. Same week, same build, same tester, completely different question.

They get conflated because both happen after a change, both produce green results, and both are reported in the same sentence. The vocabulary collapses long before the thinking does.

What Each One Fails to Tell You

Run only the retest, and you know the reported symptom is gone. You know nothing about what the fix moved on its way there. Most fixes are edits to shared code and shared data, and the reason a defect is worth this whole conversation is precisely that the area is delicate enough to have broken once already.

Run only regression, and you get a different blind spot — and it is the less obvious one.

The suite that passes is the suite of tests that existed. The test that found the defect almost certainly was not in it. It was constructed during investigation, out of a specific sequence somebody stumbled into, and it lives in a defect report rather than in the pack. So a full green regression run can be entirely consistent with the original bug still being there, because nothing in the pack has ever exercised it.

That asymmetry is the practical heart of the distinction. Regression cannot confirm a fix, because the case that proves the fix is the one case regression does not contain.

The Third Question Nobody Asks

There is a scene I have watched more than once. A developer fixes a bug, marks the ticket done, and the team moves on. The fix is real, the symptom is gone, everyone is satisfied.

Nobody asks why the unit tests did not catch it. Nobody asks why smoke did not catch it.

A fix without that question is mopping the floor without turning off the tap. The floor is clean. You will be back.

And it is not a philosophical question — it has a concrete output. The answer tells you which layer of the net has a hole in it, and therefore where the new test goes. If a unit test should have caught it, the new case belongs in the unit suite, and adding a UI case instead is an expensive way to not fix the problem. If nothing at any layer could have caught it, that is a finding about your test design, not about this bug.

Three Questions, Three Answers, After Every Fix

The rule I use is that a fix owes you three separate answers, and none of them substitutes for another.

Did the fix do what it claims? That is the retest, and it runs the exact reproduction from the defect report — same data, same sequence, same environment shape.

What else did the change touch? That is regression scope, and it is derived from the change, not from the symptom. Ask the developer what the fix modified, then work outward from there.

Why did the existing tests not catch this? That is where the new permanent case belongs, and it is the only one of the three that improves anything for next time.

Skip the first and you have not confirmed anything. Skip the second and you have traded a known defect for an unknown one. Skip the third and you have agreed to see this again.

Two Habits That Make It Stick

Neither of these needs a process change or anyone's approval.

• Name the activity when you report the result. Write "retested, passed" or "regression pack run on the fix build, passed" rather than "tested." It sounds pedantic for about a week, and then it starts catching the cases where somebody assumed the other half had been done by somebody else. Ambiguity in a status report is not neutral; it is where two people can both believe the work is covered.
• Promote the reproduction into a permanent case the day the defect is fixed. The sequence that found the bug is the most valuable test artefact the incident produced, and it dies inside the defect report unless somebody moves it. That promotion is what converts a one-off retest into regression coverage for every release after this one.

The second habit is the bridge between the two activities. Today's retest is next release's regression case, but only if somebody carries it across.

Why the Distinction Keeps Dissolving

Both activities produce the same artefact: a passed result on a fix build. From the outside they are indistinguishable, and the language everyone uses in stand-up flattens them into one word.

So the distinction has to be maintained deliberately, by the person doing the work, in the way they write it down. Nothing about the tooling will enforce it — the tracker does not care, and the run report looks identical either way.

Retest confirms a fix. Regression protects what was already working. A programme that only does the first ships surprises; a programme that only does the second reopens the same defect two sprints later and treats it as new.

After the last fix your team shipped, which of the three questions actually got an answer?