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 :
- 1. Early detection of defects
- 2. Maintaining high-Quality Product
- 3. Gives confidence to the team that there is no broken functionality
When to do Regression Testing?
- 1. An addon functionality is implemented to the existing functionality
- 2. Change Request is implemented
- 3. After Bug Fixes/Performance fixes
- 4. When an environment is subjected to changes
Best Practices in selecting Test Cases for Regression
- 1. Test Cases which usually result in bugs
- 2. Test Cases of the Core Functionality
- 3. Test Cases of Integration Flow
- 4. Test Cases that have undergone a 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
- 1. Reusable Test Cases – Once Designed it can be used repeatedly whenever there is a need to execute the regression suite
- 2. Dormant Test Cases – These test cases are not used until if any bugs are noticed in these areas
Regression – Manual or Automation?
Usually, regression testing is a tiresome process and laborious. On 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 wasting 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 hotfix release, we tend to do the selective regression testing
Progressive Regression Testing: It is done when 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: Regression testing helps ensure the applications are not negatively impacted by the new additions or changes to the application.