“What is the difference between regression testing and retesting?”
It’s an all too familiar situation: you’re in a software testing interview, potential employer asks you to answer the question above and you go blank. You then start to ask yourself: “What exactly separates the two types of tests from each other? Why is this an important question and why is this so confusing?”
Don’t let this happen to you. Learn what differentiates regression testing from retesting now. In fact, we’ll provide a little shortcut for you by getting down to basics and explaining a bit about each test.
A few weeks ago, we shared a blog that focused specifically on regression testing. We discussed why it’s important and how it’s used. Now, let’s go over it one more time within the regression testing vs. retesting framework to gain a better understanding.
Regression testing is a functional testing method that re-executes test cases in order to find errors brought about by changes or corrections made to a specific module or all modules during software development and upkeep. In other words, regression testing doesn’t necessarily target any specific fix or code change; instead, it tests to check that changes made didn’t impact other aspects of the software application.
Generally, regression testing is incremental. For instance, as new functionality is added or a defect is amended, new test cases are created and added in order to perform regression testing afterward.
Retesting runs test cases that previously failed when ran to ensure an issue has been fixed, in contrast to regression testing which runs test cases that had previously passed. Additionally, unlike regression testing, which tests an area or an entire application, retesting targets particular defect fixes or specific functionality. Another way to put it is that with retesting your scope is fairly narrow, while with regression testing your scope is broader.
Retesting is generally viewed as planned testing, whereas regression testing is seen as generic testing. In some cases, for instance larger projects, retesting and regression testing can run parallel with each other. Typically, however, you would retest first and only begin regression testing once retesting is complete.
For example, say you enter valid input into the login field, but an error message pops up instead. This would mean there was some sort of defect with the application. The tester would then make the developer aware of the defect so that they can fix the issue. Once the developer fixes the defect, the tester would then retest the login module to ensure it is working correctly and the defect truly was corrected. Regression testing would then take place after retesting to determine if the fix to the login field had any impact on other aspects of the application.
To summarize, retesting verifies the fix only. Regression testing, on the other hand, tests specific modules or all modules when a change or fix is made, so as to see what, if any, effect the change or fix has made to unchanged parts of the application. In the end, while both have different objectives, they’re equally pertinent to the amount of success your project garners.
Use both and know both tests to truly see your product flourish in today’s market.
You can find more questions that a manager can ask you here in this article: Selective QA Interview Questions for Managers to Ask.