What is the Difference Between Retesting and Regression Testing:
Don’t you all love the compare and contrast themed articles? I know I do. It is such a great way to invite thoughts, comments and maybe even, strong disagreement.
Today’s topic is Retesting Vs Regression Testing.
Let’s begin with Retesting:
What You Will Learn:
Retest means to test again. The reason does not matter. When you repeat a test, you retest. You could retest current version functionality. Or a bug fix, previous version functionality, a test case you just ran, etc.
If you are still thinking- why- then the following are some reasons that are as good as any:
- You ran a test yesterday and ran into a defect. You want to confirm the steps and the defect’s reproducibility. So, you retest.
- You ran a test. Your attention wasn’t on it (Maybe your phone rang, or you were talking to a colleague, etc.). You want to check once more, so you retest.
I’m sure you get it.
Retesting is when you repeat a test for any reason. It is one of those terms that stay true to its definition.
Software evolves. There are going to be new versions over existing ones. There is piling on of new features, extensions, etc. But, over time, this could lead to instability of the application.
Imagine yourself making a block tower, by adding one block over the other. You don’t take the time to reinforce or strengthen the base. It won’t be long before the tower crashes, isn’t it?
Just like that, you will have to test the software’s base for strength and stability.
To do so, we would have to retest the software. That is the only way.
Recommended read => What is Regression Testing? Tools and Best Practices
Regression is a form of Retest. The specifics of “Why” and “When” is what differentiates it from the former.
1) When are we retesting? When software undergoes a change
2) Why are we retesting? To ensure the new additions/changes have not made the before working functionality unstable. Regression is common and recommended when:
- A new version becomes available. (Regress all or, at least, the important of the older version features)
- Bug fix
Point to note: Exhaustive Regression testing is impossible though desirable.
That’s why do Regression Analysis before you jump straight into testing. This step involves deciding how much regression I should be doing for my application.
What does the extent of regression depend on?
- Nature of the change
- Relationship/impact of the change on the current system/feature
- Available time and resources
How can testers decide the extent of regression?
1) Through experience and familiarity with the application
3) The place where the change has been made. For example: if it is on the home page, then it needs more attention than if it was in one of the less accessed pages.
Depending on the factors at play, a test team could go for one of the following:
- Unit Regression
- Partial Regression
- Full Regression
Unit regression means you retest the changed module/area of the application ONLY.
Partial regression means you retest the changed module. Plus include those that interact with it.
Full regression is you test the entire application irrespective of the location of change.
It depends on the situation (time & resource availability), the seriousness of the change (its impact), your developer’s inputs etc. You will be more efficient when you choose the right set of tests vs. all the tests.
Regression Analysis is the key success factor. It needs smart work rather than hard work.
Misconceptions about Regression Testing
There are many misconceptions about Regression Testing:
#1) Regression is always done via automation: No. Regression is done manually too. We have a whole article on this => How is Regression Testing Performed? Can It be Done Manually?
Note that regression is a perfect candidate for automation. The extent of repetition is time-consuming and could lead to boredom. Also, important validation could get missed out. Automation is a reliable, fast and efficient alternative.
Also read => Automated Regression Testing Challenges
#2) Regression is never complete: True. But not completely.
What I mean is, an exhaustive regression test might be impossible. But, exhaustive regression testing might be unnecessary too.
Let’s say you changed a misspelling on the home page. This fix is minor. It is also isolated from the other areas of the application. So, a simple retesting of the feature would do. No need to regress the former functionality around homepage.
#3) It is unnecessary when you have a crunch for time: Not true. Not enough regression leads to a lack of confidence in the product. You will never know what to expect from its reaction to different end-user scenarios.
#4) It is running every single test case of the previous release: Once again, choosing every test case is not the right way to do this. Strategic picking of the test cases is the key. Understand the change and choose the fitting test cases.
OK, That is Retesting and Regression Test in detail.
Now, The comparison.
Retesting Vs Regression Testing
What is same about them?
- They are both repetition based
- Validation and Black box testing techniques
- Automation or Manual test cases both get retested or regressed
- “One must verify or expel his doubts, and convert them into the certainty of Yes or NO- Thomas Carlyle”. Both of them do this.
What is different about them?
- Retesting is applicable for any test – Current or previous version functionality targeted. Regression is previous version functionality centric.
- Retesting is not dependent on applicable change. Regression is change oriented.
Finally, to hit this concept home:
Let’s say you have a Test case XYZ that resulted in a defect with the ID 120. This defect gets fixed in the next release. You would retest XYZ test case and regress the functionality around it. The regression is to make sure that everything is working intact after 120’s fix. The retest is to determine the defect’s fix.
So, it is neither one nor the other, but the combination of regression and retesting that forms the dynamic duo.
Now, it’s over to you. Do you agree with the definitions and analysis provided here?
About the author: This article is written by STH team member Swati S.
What are your thoughts, comments, and questions on this? Please do share and we would love to connect with you all.