• info@helpingtesters.com
  • helpingtesters

When is the Right Time for Regression Testing

July 14, 2017
Regression Testing, Types of Regression testing, how to do regression testing, ReTesting

Every software application once developed contains many issues which can affect the functionality, performance, and aesthetics of the application. Most of these issues are identified at feature level by the testing team. But when many features from different modules are put together, there are high chances of new defects being introduced. These issues come up when independent modules start interacting with each other. Also, the code changes made for any existing issue fixes can impact some other part/ module of the application. For this reason, regression testing is performed by every QA team. 

Even though its importance is prominent, what is the right time to perform it? Should every QA member be part of regression or should regression be done at a certain period of time? In this post, we would talk in depth about the right time for regression testing and how many resources should be allotted for regression?

Difference between Retesting and Regression Testing, with Example

The difference between retesting and regression testing is a basic testing concept. Let’s take an example to explain both these functional testing methods.

An application has a log-in page and a dashboard. The user can visit dashboard by using different user credentials. But while testing two issues were encountered. In the log-in page, the username was case sensitive. Ideally, the username shouldn’t be case sensitive. While the second defect in the dashboard was, the username that was entered in the login page was being displayed as is on the dashboard. Now let’s use this example to understand the difference between retesting and regression testing.

  • Retesting – In retesting, the testing team would test the issues individually and ensure that the bugs are actually fixed by the developers. Once fixed, the bugs would be marked as closed.
  • Regression testing – Even when retesting is done and the bugs have been marked as closed, it doesn’t mean that the application is free from any issues. Regression testing would ensure that the individual bug fixes doesn’t introduce any new errors or jeopardize the integrity of the application. To do so, the testing team would test the application throughout and check the interaction between the login page and the dashboard. They would use multiple authentications and test the session of the application so that log-in data properly persist within the same session and not across different sessions.

When to do Regression Testing to get the best Result

One of the primary concerns of the QA team is to accommodate regression testing along with other testing deliverables. If the team is unable to perform regression testing, due to the priority of other testing deliverables, the quality of the product would degrade. It also increases the chances of encountering bugs late in production. So, how should the testing team allocate resources for regression while dealing with releases? And when should regression testing be done? if you want to know complete details of Software Testing Process than opt for Software Testing course.

For an Agile project, the most effective timeline for performing regression testing are below:

At Sprint end/ Sprint start – When the sprint ends, the testing team would ideally have all the features which have been developed, and they would already be tested (individually). Now before sprint demo or demoing the product to the client, the testing team should allow most of the testing resources to perform regression testing of all the features being delivered in the sprint.

  • Such brute force testing would squeeze out any possible issues that might reside in the application. This would also ensure a stable build and a smooth client demo.
  • Regression can also be done at the start of the sprint, but the items that would be targeted would be from the previous sprint. In this case, half of the testing team should be involved in regression testing while the other half should indulge in requirement grooming and writing test cases and scenarios.
  • In either of the cases, the bugs identified would be logged and pushed to product backlog for the developers to take up in subsequent sprints.

 

Before minor/ patch releases – If there is resource crunch in the testing team or the Sprint estimates and team velocity doesn’t provide any scope of regression, the team can take up regression testing during minor releases or patch releases.

  • With this approach, the whole testing team must devote their complete time towards regression testing and keep some window to retest the bugs and perform another round of regression once the bugs are fixed by the developers during the first regression.
  • Depending on the vastness, the complexity of the application, and the size of the testing team, regression testing shouldn’t take more than one sprint (10 to 14 days). With such an approach, the regression testing would ensure a stable release.

 

Before production release – Performing regression testing only before production release is never recommended. Regression before production release should be conducted along with regression tests as mentioned in the earlier points.

  • Regression before final release or production should be conducted at least two sprints in advance so that the developers and testers get ample time to add quality to the product in their own manner.
  • Generally, if the regression testing in the early stages (sprint/ patch) is done properly, the number of issues encountered before production release would be minimal. In case issues are found, the high priority ones should be addressed immediately, while the cosmetic and trivial issues should be attended to in the end.

 

Automated regression suite for post-production – Automated regression suites are considered to be the final line of defense once the application is pushed to production and is used by the customers/ users.

  • The important business flows should be identified with the help of the clients and stakeholders and converted into scripts so that the regression test suite results can be monitored to evaluate the health of the application at any point of time.
  • As the creation of such suites can take up a lot of time, automation testers should start creating them way in advance. The focus should be quality tests and non-repetitive test data. Also, the more such test cases are created the better confidence the testing team and product owner would have once the project is handed over to the actual consumers.

 

NOTE – Whichever timeline is fixed for running the regression tests, the testing team should update the clients about the details of the tests, flows covered and defects identified. If the client feels more regression should be accommodated, the testing lead should plan accordingly and increase the number of resources allotted for such tests.

 

Conclusion

  • Functional testing of individual features and integration testing of the system alone is not enough to ensure the stability of the application. Regression testing must be performed to filter out any issue that might reside due to different interacting modules.
  • Depending on the availability of the testing team, the regression testing should be performed during every sprint, or during minor/ patch releases and also before production release.
  • Automated regression suites should also be in place so that the application can be checked even after the build is pushed to production without involving any testing resource.
  • The regression plan should be documented in test plan document and the results of every regression tests should be shared with the clients and stakeholders.

 

About the author

arindam bandyopadhyay author

Arindam Bandyopadhyay is an automation tester with over 5 years of experience in software testing. While during the day he juggles between Eclipse and spreadsheets, at night he lets his fingers do the talking as he writes about anything and everything his paradoxical mind desires.

Leave a Reply

Your email address will not be published.