We have explained in detail the difference between Retesting and Regression Testing:
Do you all love the compare and contrast themed articles? I really do. It is really a great way to invite thoughts, comments and even strong disagreement.
The topic we are discussing today is Retesting Vs Regression Testing.
Table of Contents:
Retesting Vs Regression Testing
=>Â Click Here For The Complete Regression Testing Series.
Let’s begin with the concept of retesting:
Retesting
Retest means to test again. The reason does not matter. When you repeat a test, you retest. You can retest the 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 may 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.). Just wanted to check once more so you can retest.
I’m sure you’ll get it.
Retesting is when you repeat a test for any reason. It is one of those terms that stays true to its definition.
Regression Test
Software always evolves. There are going to be new versions over the existing ones. We are piling on of new features, extensions, etc. But over a period of time, this could lead to instability in 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, right?
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? Ensure new additions/changes have not made the previous working functionality unstable. Regression is common and is recommended when:
- A new version becomes available. (Regress all or, at least, the importance of the older version features)
- Bug fix
Points 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 is the extent of regression dependent on it?
- Nature of the change
- Relationship/impact of the change in the current system/feature
- Available time and resources
How can testers determine the extent of regression?
1) Through experience and familiarity with the application
2) Discuss with the developers
3) 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 testing 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 when you test the entire application irrespective of the location of the 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 of Regression Testing
There are many misconceptions about Regression Testing:
#1) Regression is always done via automation: No, this is not true. Regression is done manually as well. We have a whole article on this => How is Regression Testing Performed? Can It be Done Manually?
Note that regression is the perfect candidate for automation. The extent of repetition is time-consuming and could lead to boredom. Important validation could also 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. However, exhaustive regression testing might be unnecessary too.
Let’s say you changed the misspelling on the home page. This fix is minor. It is also isolated from other areas of the application. So, a simple retesting of the feature would do. No need to regress the previous functionality around the homepage.
#3) It is unnecessary when you have a crunch for time: This is 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 from the previous release: Once again, choosing every test case is not the right way to do this. Strategic picking of test cases is key. Understand the changes and choose the fitting test cases.
Ok, that is the Retesting and Regression Test explained in detail.
Now, let’s look at the comparison.
Retesting Vs Regression Testing
What is the same about them?
- They are both repetition based
- Validation and black box testing techniques
- Â Automation and 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 the earlier version functionality centric.
- Retesting is not dependent on applicable changes. Regression is change oriented.
Finally, to hit home on this concept:
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.
It’s over to you now. Do you agree with the definitions and analysis provided in this article?
About the author: This article was written by STH team member Swati S.
What are your thoughts, comments, and questions on this? Please do share in the comments section below and we would love to hear and connect with you all.
=>Â Visit Here For The Complete Regression Testing Series.
I have one question for Regression testing that
If suppose you received and accept a built and while testing any feature you get one bug and this has been reported to developer also.Now the question is will you go for further regression testing to test that feature.
Explained in beautiful way.
Great explanation,thank you
A detailed difference between retest and regression give the idea about the basic concept of these terms. Thank you
Great insights related to the regression testing. Regression testing automation solution helps you determine obstructed functions and features for specific releases ensuring minimum risks into production and maximum test coverage.
@Vignesh: I think it is not an either/or situation. Sanity test is usually limited and focuses on the key areas only. Regression is more extensive.
@Purushothaman: By Entry and Exit criteria I assume you mean: When to start them and stop them. Well, when to start is the easy part: when the fixes or changes become available. When to stop: It depends on the extent of coverage desired, if all bug fixes are verified,etc. These things hold good for both retest and regression mostly, but retest does not necessarily call for a new code deployment. I hope this helps!
Good Job.
@All: Thank you for the positive feedback!
what is the outcome of the regression testing and retesting – exit and entry criteria?
Please let me know if you have an complete idea.
I have one question for Regression testing that
If suppose you received and accept a built and while testing the feature you get one bug and this has been reported to developer also.Now the question is will you go for further regression testing to test that feature.
Very good view for the difference between the Retest and Regression Test, really you mentioned the basic concept perfectly.
in short, regression testing is check the stability of the application resulting from a recent defect fix.But, in what way do Sanity testing connect to regression. Either regression or sanity, which proves a better option?
You always makes it so simple! 🙂