Regression Testing Best Practices
Functional Testing Industry Wisdom

How to do Regression Testing | The Best Practices

Whatever you say for your regression approach – still a high percentage of projects execute regression the wrong way. Or let me put it in better words – a high percentage of projects do not follow the regression testing best practices. That’s why we say Regression Testing is One of the most Important yet Neglected Test Type. But what is the right approach to Regression Tests? Or what are the Regression Testing Best practices to-be-followed to effectively identify any side-effects of recent changes? Let’s explore…

The problem with Regression Testing

Agree or not but over a period of time, Regression Testing has become boring. Nobody likes the ‘Rework’. Nobody wants to test the same functionalities again & again. Nobody takes the regression seriously. It is just for the sake of it that 30% of the test cases from current & previous releases are executed, either manually or automated. Nobody bothers to look at Regression Testing Best practices!

Regression Testing serves dual-purpose

What many people ignore is the fact that Regression Testing serves dual purpose – building the confidence that major functionalities are working as expected (no side-effect) + identifying any residual defects (side-effects). It is imperative to draft a proper approach including Regression Testing Best practices for a successful project delivery and avoid any future embarrassments (production defects).

Regression Testing Best Practices

The Automated Regression Suite

The perfect application of Automation testing – Regression. Why? Because the application is already developed & somewhat stable, ready to be automated 😉 the first of all the popular regression testing best practices for a successful project delivery anywhere in the world – maximize your automation returns during regression testing!

Get rid of the Pesticide Paradox

One of the seven fundamental principles of Software Testing – If you keep running the same set of tests over and over again the software gets immune to testing, i.e. as the system evolves, many of the previously reported defects will have been fixed and the old test cases cannot find any new defects. It seems perfect in the case of Regression Testing. The new tests are added to the regression suite to-be-executed in next release, making it bigger & bigger. Though boring, but it is imperative to rework the regression test suite with every release. It’s of no use in wasting time & effort running the same test cases again & again without any positive results!

Impact Analysis

How do you get rid of pesticide paradox? How do you rework on regression suite? Yeah! Impact Analysis is the foundation. In order to gauge the side-effects of changed code – first & foremost you should know the impacted areas. It’s of no use to check for a leg injury when the problem is with the back 😉 How do you do Impact analysis? Developers, architects & business analysts might help here!

Focus on Risk-based Testing

As we wrote earlier – first test what matters the most. The 80-20 rule applies to almost everything in life. Every application or product has certain features which are / will be used the most by the end-users. Focus on these high-priority functionalities first – ensure it is working fine and then if time permits move on to other functionalities. In an ideal case, a full regression test is desirable but oftentimes there are time/resource constraints. Post rework & impact analysis – Test cases should be prioritized & executed in that order. I.e. dividing the test cases in multiple priorities ranging from priority 1 to 3 or 4.

The Defects might help

Since regression testing is done at the end of release cycle when the functional testing is completed >> defects have been fixed, retested & closed >> the code has been frozen (no more changes allowed), we already have a long list of identified defects. One of the regression testing best practices would be to retest all these defects since most of the time older defects get reopen. It is good to ensure that the current functionalities are working as tested earlier!

Plan the Regression Testing

Though important, still Regression testing is one of the most neglected concept in Software Testing. In most of the cases, companies don’t have some well-defined & implemented policy towards regression testing. It is not given its share of due importance, i.e. proper planning. The focus is always on the new functionality and the new tests. We don’t say that don’t focus on it – but never neglect ‘Regression Testing’. Always plan your efforts with a strategic approach keeping in mind the Regression Testing Best practices!

In today’s world of extremely complex devices and software applications, the quantity and quality of regression testing performed on a product are directly proportional to the commitment vendors have to their customer base. For regression testing to be effective, it needs to be seen as one part of a comprehensive testing methodology that is cost-effective and efficient. Regression testing is not an option, it’s a requirement.

These best practices will ensure that regression testing is done smartly and with the right approach. What are your opinions on regression testing? What do you think are the Regression Testing Best practices? We’ll love to hear your comments below.

3 thoughts on “How to do Regression Testing | The Best Practices”

  1. Good article. I particularly like the sound advice to ‘rework the regression test suite with every release’. Because this is often daunting due of the size of existing regression test suites, an incremental approach (rework a bit at a time with each release) may help. Also I agree that ‘planning the regression testing’ is key to success and it is worth adding that this planning should be included with the planning for new release work, i.e. when adding new functionality consider what regression testing is likely to be required in the future. As you imply, a good regression test suite is just as much a part of a good product as the source code … well, almost!

Leave a Reply

Your email address will not be published. Required fields are marked *