What is the difference between retesting and regression testing?
- Retesting: run the exact test case that failed, after the fix, to confirm that specific bug is gone.
- Regression: run the surrounding tests to confirm the fix didn't accidentally break existing functionality.
- Retesting is about the bug. Regression is about everything else.
The long answer
These are two separate activities triggered by the same event — a bug fix landing.
Retesting is narrow. You take the exact test case that exposed the bug, run it again on the fixed build, and verify the defect is resolved. Nothing more. One test, one purpose.
Regression testing is broader. You run tests across the areas that the fix could have touched, to confirm no existing functionality was broken as a side effect of the change. This is why regression exists — every code change carries a risk of unintended consequences elsewhere.
In practice, both happen together after a fix: first retest the failed case, then run the relevant regression slice around it.
How this connects to sanity (Concept 3). When a bug fix lands, running the tag-filtered sanity slice already does both jobs described here: the specific test that exposed the bug gets retested, and the surrounding tests under the same feature tag double as the regression check. Retesting and regression aren’t a separate step from sanity — sanity is retesting plus a scoped regression, run together as one filtered pass. Example: forget-password gets fixed → filter by the forgot_password tag → the reset-link test retests the fix, the rest of that tag’s tests are the regression check, and the whole run is called “sanity.”
Saying retesting and regression are the same thing, or that regression means "running everything." Regression means checking existing functionality wasn't broken — the scope can be narrow or broad depending on the risk of the change.
