You’re not the only one scratching your head about the difference between regression testing and retesting.

Many people get these two software testing types confused because they have a lot in common. Both are types of functional testing. Both take place after development.

Yet they’re different in big ways.

How so?

Let’s cover them individually before we get into the differences.

What Is Regression Testing?

Basically, regression testing is a type of software testing that ensures an application still functions as it should after any changes to the code, UI, or other high-impact activities. Regression testing helps answer the question, did the change create any new bugs?

There are many regression testing types. Each helps reduce risk associated with change by making sure an application stays stable.

Check out this eBook on regression testing for more insights.

What Is Retesting?

Retesting is testing a defect again — after it has been fixed.

When a tester finds a bug, it gets assigned to a developer. After the developer addresses it, the tester verifies it has been fixed by retesting.

Retesting helps answer the question, is the bug we found gone?

Regression Testing vs Retesting: What’s the Main Difference?

Think of it like this: Regression testing = find new bugs. Retesting = confirm bugs were fixed. Regression testing locates bugs after updates or changes to the code or UI. Retesting makes sure that a bug that was found and addressed by a developer was actually fixed

More Differences Between Regression Testing & Retesting

The definitions of regression testing and retesting continue to diverge when we look at priority, ability to automate, and test execution.

Regression Testing	Retesting
Find new bugs	Confirm fixes to old bugs
Automate	Manual
Lower priority	Higher priority
Executed broadly	Executed discretely
Unplanned work	Planned work

Regression testing is executed broadly, across an application, to identify new issues. Because of the scope and scale (there many different browsers and versions to test against), regression testing is commonly automated.

Retesting is executed discretely, often one test at a time, by a manual tester who validates an issue was fixed. Because retesting is conducted on known issues, it’s often higher priority than regression testing.

Finally, retesting is often more predictable compared to regression testing, which finds new issues and thereby creates work you didn’t plan for or expect.

Regression Testing vs Retesting: Agile Example for a Web Application

Now let’s imagine there was an update to your Salesforce instance, and you wanted to make sure that those changes didn’t cause your application to regress (aka revert to a non-working state). By executing a test suite designed for regression testing, you can discover what, if anything, is no longer working in the application.

If you’re conducting regression testing in an Agile environment, you would schedule the testing regularly across different browsers to make sure your changes weren’t creating unexpected bugs for your end users.

Regression testing is easier when you have a codeless test automation tool that lets you schedule regression test suites that are executed simultaneously across multiple browsers. It’s how teams improve efficiency and quality at the same time.

Conclusion

Regression testing and retesting sound similar at first, but when we drill down below the surface, we discover they differ in essential ways.

One last time: Regression testing confirms that application changes didn’t create a new bug. Retesting confirms whether a bug was successfully fixed by a developer. It’s as simple as that.

For more on regression testing, including the role of codeless test automation, check out the eBook >>