Regression testing vs retesting
Retesting re-runs the exact steps of one reported defect to confirm that its fix works. Regression testing re-runs a wider set of tests over behaviour the fix was not supposed to affect, to confirm nothing else broke. Retesting is narrow and tied to a ticket; regression testing is broad and tied to the build, and a team doing one of them still needs the other.
The longer version
The two take different inputs and answer different questions. Retesting asks whether one specific defect is gone, and its input is that defect's report: the steps to reproduce, the environment it happened in, the behaviour that was expected. Its output is a verdict on one ticket, which either closes or reopens. Regression testing asks whether anything that used to work has stopped working, its input is the suite, and its output is a verdict on the build.
Order matters between them. The retest comes first, because a broad pass over a build where the fix never landed spends its whole runtime confirming a failure somebody already knew about. A green regression run is also no substitute for it: the suite usually has no case covering the defect at all, which is part of why the defect reached a user instead of a pipeline.
Automation is where the two connect. A retest exists for a single ticket, so scripting it has no second use while it stays attached to that ticket. Keeping the script and moving it into the regression suite once the fix passes is what gives it one, and it is how a suite ends up holding a case for every defect the team has already met. Retesting is the moment a check gets written; regression testing is the rest of that check's life.
The neighbouring comparisons resolve the same way, on scope and trigger rather than on depth. A smoke test is triggered by a new build and covers the few paths that decide whether testing continues. A sanity test is triggered by one change and covers the area that changed. A retest is triggered by one fix and covers one defect. Regression testing is triggered by any change and covers everything that used to work, which is why it is the slow one and the one the others get compared against.
Common questions
Which comes first, retesting or regression testing?
Retesting. It takes minutes and it answers whether the build is worth a broad pass at all. Running the suite first against a build where the fix never landed spends the run confirming a failure that was already reported.
Is retesting the same as confirmation testing?
Yes. Standard testing vocabulary calls the activity confirmation testing, and most teams say retesting for it: running the reported steps again against a build that claims to have fixed them, and closing or reopening the ticket on the result.
Does a passing regression suite mean the fix works?
Only if the suite already covers that defect, and usually it does not, since a case covering it would have caught the bug before anyone reported it. The suite reports on the behaviour around the fix. The retest is the only check aimed at the fix itself.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.