Regression testing
Regression testing is a type of change-related testing that detects whether defects have been introduced or uncovered in unchanged areas of the software. In practice it means re-running existing tests after a fix, a new feature or an update, to show that behaviour which already worked still works.
Submit a project Check your release readinessReviewed by Huy Nguyen (David), CEO · Updated 27 Oct 2026 · 4 min read
This term is one of the entries in the OutsourcingVN glossary of words buyers meet while judging whether a release is ready.
Why does regression testing matter?
A fix or a new feature touches code that other, unrelated behaviour quietly depends on, so a change that works exactly as intended can still break something a user relied on elsewhere in the same release. OutsourcingVN is operated by Netbase JSC, and the reason regression testing sits beside testing the new behaviour itself is that the two answer different questions: does the change work, and does everything that already worked still work, and a release plan that only asks the first question has no way of catching the second kind of failure before a user does.
What is an example of regression testing in practice?
A team adds a second delivery option to an online store's checkout. The new option is tested on its own first, confirming it calculates cost and schedule correctly. Regression testing then re-runs the existing checkout journeys that were not meant to change: card payment, a different delivery option already in use, and the order confirmation email, to confirm none of them now behaves differently because of the change. One of those journeys turns out to send the wrong confirmation email after the update, a defect regression testing catches before the release reaches a customer, even though nobody was deliberately testing the email path.
What are the common misreadings of regression testing?
Regression testing is not the same as confirmation testing, which is performed after fixing a defect to confirm that a failure caused by that defect does not reoccur; regression testing instead checks areas that were not expected to change at all. It is also not the same as user acceptance testing: see user acceptance testing for that definition, since UAT checks that a release fits the buyer's own work, while regression testing checks that existing behaviour has not broken, and the two are usually run at different points before a release. Smoke testing is narrower again: it only gains enough confidence that a test object is ready for planned testing, rather than re-checking the fuller set of existing behaviour regression testing covers.
Plan the next step for your project
Common questions
No. Any change can introduce or uncover a defect in an unchanged area, so it follows a new feature or a dependency update as well as a defect fix.
Yes. An automated suite can re-run existing checks after every change, so an unintended break shows up without re-testing everything by hand before each release.
Which decisions does regression testing affect?
Deciding which journeys must pass regression testing before a release ships, and what counts as evidence that they did, is part of the software release readiness checklist, alongside the acceptance criteria set out in software acceptance criteria. When you know which existing journeys a change must not break, describe them and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.