Retest Vs Regression Testing – How Much Regression Testers Should Be Doing?

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 the difference between Retesting and Regression Test.

Let’s begin with Retesting:

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.

retest-vs-regression-testing

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.

Regression Test:

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? 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

2) Discussing with the developers

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, 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 home page.

#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.

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.




Recommended reading

14 comments ↓

#1 Prashant

You always makes it so simple! :)

#2 Purushothaman

what is the outcome of the regression testing and retesting – exit and entry criteria?

Please let me know if you have an complete idea.

#3 Vivekananda D Shetty

Good Job.

#4 Lakshmi

Great explanation,thank you

#5 Ahmed Fathi Elgaly

Very good view for the difference between the Retest and Regression Test, really you mentioned the basic concept perfectly.

#6 Viral Patel

A detailed difference between retest and regression give the idea about the basic concept of these terms. Thank you

#7 pradeep

Explained in beautiful way.

#8 Vignesh

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?

#9 Swati Seela

@All: Thank you for the positive feedback!

#10 Swati Seela

@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!

#11 Swati Seela

@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.

#12 Anuj36

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.

#13 Anuj36

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.

#14 Pratik P

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.

Leave a Comment