Regression testing vs retesting

The difference in one table

Examples

Retesting: suppose a coupon wrongly applies to an excluded item. After the fix, use the same excluded item, coupon and account conditions that reproduced the defect. Check the total and the saved order, rather than accepting a success message as proof.

Regression: then check eligible items, mixed carts, coupon removal and refunds. These checks ask whether the fix changed behaviour that used to work. Include other callers of the same discount calculation, not only the screen where the defect appeared.

How to answer in an interview

Retesting confirms a particular defect is fixed by repeating the conditions that exposed it. Regression testing checks for unintended effects of a change on existing behaviour. For a coupon fix, I first repeat the failing excluded-item case, then check eligible items and other discount flows. I choose the regression scope from impact and risk rather than automatically running every test.

Common confusion

Do not say regression only checks unrelated modules: the changed module can regress too. Retesting is often called confirmation testing; some teams use “retest” for any repeated execution, so clarify the purpose. A passed confirmation check does not prove that the wider release is safe.

Likely follow-up: What if the original case still fails? Reopen the defect with the build, data and evidence; investigate other changes where useful, but do not record the fix as confirmed.

This is independent foundation-level learning material, not affiliated with ISTQB.