Regression testing vs retesting trips people up because both involve running tests you've already run. The difference is the question being asked. Retesting asks: is this specific bug actually fixed? Regression testing asks: did recent changes, including that fix, break anything that used to work? Retesting is narrow and targeted. Regression is broad and defensive. You can pass one and fail the other, and releases go wrong precisely when teams do the first and skip the second.
Retesting: verifying the fix
Retesting is planned around a specific defect. The bug had reproduction steps; the fix landed; I run those exact steps on the new build, with the same data and device that produced the failure, plus a few variations around the edges. If the bug is gone, the ticket moves to closed. If not, it's reopened with notes. Retesting is always deliberate and always manual-first, because the whole point is human confirmation that a known failure no longer happens. You cannot skip it, and you cannot substitute it with a green regression run, since your regression suite probably never covered the exact broken path in the first place. That's often why the bug existed.
Regression testing: checking the blast radius
Regression testing assumes something different: that any change, however small, can break distant behavior. A fix in the session-handling code can take down logout, deep links, and push notification routing, none of which are mentioned in the ticket. So a regression suite re-runs a standing set of tests covering the features that already worked. It isn't tied to one defect; it's tied to the change itself and everything the change might touch.
A sprint example
Mid-sprint, a developer fixes a bug where the app crashed when a profile photo upload was interrupted. My afternoon looks like this. First, retesting: reproduce the original steps on the fix build, interrupt the upload the same way, confirm no crash, try a couple of nearby variations like airplane mode mid-upload. Twenty minutes, ticket closed. Then, regression: the fix touched the upload and media-handling code, so the automated suite covering profile editing, image attachments in chat, and gallery permissions runs against the same build. I didn't choose those tests because of the bug's symptoms; I chose them because of where the fix lives. That's the practical difference in one afternoon: retesting follows the bug, regression follows the change.
How they combine in a release cycle
Across a release, the two interleave on a rhythm. Every fixed defect gets retested as it lands, one at a time, throughout the sprint. Regression runs on a broader cadence: a small smoke-level pass on every pull request, the full suite nightly, and one complete regression run on the release candidate after the final fix is merged. That last run matters most, because late fixes are made under deadline pressure, which is exactly when blast radius gets misjudged. If the release-candidate regression passes and every open defect has been retested, the build ships.
Automation implications
The two activities have opposite automation profiles. Retesting is a poor automation target: each bug is verified once or twice, and writing a script for a one-time check costs more than it saves. Regression is the best automation target in all of testing: the same suite, run identically, dozens of times per release. This is where I've spent most of my automation effort. Building our Maestro regression flows and wiring them into GitHub Actions so they run on PRs and nightly cut our regression time roughly in half, and it freed exactly the hours that retesting and exploratory work actually need. The valuable retest cases don't disappear, though: once a bug is verified fixed, the best ones graduate into the regression suite so that bug can never quietly return.
Quick check: if you're asking "is the bug gone?" you're retesting. If you're asking "is everything else still fine?" you're regression testing. A safe release needs both answers.
Keep the two questions separate and the process designs itself: retest every fix by hand, automate the regression suite, and promote your best retests into it.