You are using an older browser that might negatively affect how this site is displayed. Please update to a modern browser to have a better experience. Sorry for the inconvenience!

Regression Testing and Its Types


It is common that applications get modified for new features or bug fixes or maintenance work. These changes might affect the outcome such as broken features, bad performance, etc.

Hence,  it requires us to repeatedly test the functionality to make sure that the recent changes made don’t affect the existing flow. So, the type of testing done to make sure the quality of the product is not affected due to the recent adjustment is technically named as “Regression Testing”

Testing of a previously tested component or system following modifications to ensure that defects have not been introduced or have been uncovered in unchanged areas of the software, as a result of the changes made. – ISTQB Glossary

Benefits of Regression Testing :

  • Early detection of defects
  • Maintaining high Quality Product
  • Gives confidence to the team that there is no broken functionality

When to do Regression Testing?

  • An addon functionality is implemented to the existing functionality
  • Change Request is implemented
  • After Bug Fixes/Performance fixes
  • When an environment is subjected to changes

Best Practices in selecting Test Cases for Regression

  • Test Cases which usually result in bugs
  • Test Cases of the Core Functionality
  • Test Cases of Integration Flow
  • Test Cases that have undergone recent change

Prioritizing Regression Test Cases

Test Cases should be prioritized based on the business importance and customer use for our better understanding:

P0 –  Sanity Test Cases – Highest Project Value (basic functionality)

P1 – Test Cases that cover the core functionality/Integration Flow  – High Project Value

P2 – Test Cases that are slightly related to the recent Changes which are counted as needed in the Regression suite – Moderate Project Value

Before prioritizing the test Cases, we must categorize them into two

  • Reusable Test Cases – Once Designed it can be used repeatedly whenever there is a need to execute the regression suite
  • Dormant Test Cases – These test cases are not used until if any bugs are noticed in these areas

For more details please refer to this article:

https://www.prototechsolutions.com/regression-testing/

Regression – Manual or Automation?

Usually regression testing is tiresome process and laborious. In an average scale, it is done before (Source instance)/after(target instance) every deployment.

Types of Regression Testing

Corrective Regression : This is a type of regression testing to make sure everything works as expected but not done when any changes are made to the existing code

Retest all Regression Testing : This type of testing leads to waste a lot of time. It is like corrective regression used to make sure twice or thrice that the system is working as expected.

Example : when all the testing has been completed and there is more time available,  then the testers tend to do a round of regression in order to make sure that everything is working as expected

Selective Regression Testing : Selective regression testing includes test selection from previously run test suites and test coverage identification.

Example : In case of any hot fix release, we tend to do the selective regression testing

Progressive Regression Testing : It is done when the new changes are introduced into the system and the new test cases are designed

Example : When a new enhancement is requested from the demo, a new test case will be designed to test the new features as well as the existing features.

Complete Regression Testing : This is done when multiple changes are made to the key code of the software or when some code optimization is done

Example : Assume the whole application is modified to improve the performance of the application, then the Complete Regression is done to the systems to catch unforeseen problems

Conclusion : The regression testing helps ensure the applications are not negatively impacted by the new additions or changes to the application.