The greatest threat to the quality of software products is their change. Regression testing solves this problem. After any change in the code of a software product, defects may appear, and even experienced developers often do not suspect exactly where they will arise. This concerns not only changes in the code, but also changes in various settings, configuration, data in the database, access rights.
What is regression testing?
Regression testing (definition) is testing the functionality of the software after making changes during the system testing or product maintenance phase. After the next release, the regression tests confirm that the changes did not affect the performance of the rest of the functionality of the application. Regression testing is done manually or by test automation. The problem of regression testing of software is to choose between full and partial retesting. Partial testing controls only parts of the project associated with the modified components. Repeated selective testing of the system or components to verify the modifications made should not lead to unintended effects. The task is to determine the criteria for “scale” of changes, with the achievement of which it is necessary to conduct regression tests.
For regression testing in software test cases written in the early stages of development and testing are used. This ensures that changes in the new version of the application do not damage the existing functionality. It is recommended to automate the regression tests to speed up the subsequent testing process and detect defects in the early stages of software development.
Conduct regression testing, should be after any change in functionality, in order to ensure that there are no new and / or elimination of previous errors. The inclusion of block regression testing in the development process helps protect against errors. Bugs will be detected immediately after the occurrence and will not be able to cause the propagation of errors in the application. Checking the integrity of the project after making changes is intended to test the overall functionality of the environment in which the changes were made. Every time a change is made to the system, or a new functionality is added to it, there is a possibility that these changes will affect the performance of the previously developed functionality or the system as a whole. Regression testing allows you to check the correctness of the add-ons and make sure that the program after the changes continues to meet the established requirements and successfully interacts with other systems.
Key benefits of regression testing automated procedure
- With regular regression testing – a significant reduction in the number of defects in the system by the time of release.
- Elimination of system quality degradation with increasing functionality.
- Reducing the likelihood of critical errors in pilot production.
We list the main types of regression testing in order of importance.
- Tests of version verification (Build Verification Test). We need these tests to verify the basic functionality of each version of the program. Only by being sure that the main functionality of the program is not disturbed, you can sleep peacefully. If an error is found using such tests, it is necessary to review the relevant part of the code for errors.
- Bug Verification Test. If a certain test has revealed a bug, it is necessary to carry out this test again after correction. Although conducting these tests is logical, many programmers neglect this kind of testing.
- Regression Test Pass. These tests include those that have already been conducted with previous versions of the software and did not detect errors. In the absence of time, sometimes some of the tests can be skipped (preferably only if no changes were made to the relevant sections of the code). If previously such tests have already been conducted more than 3 times, it would be nice to automate the process.
- Regression tests on corrected bugs (they are also called tests on closed bugs). What are closed bugs can be understood from the example. Let some test find an error. After correction, the same test did not detect an error. In this case, the bug is called “closed”. The bug may appear again for a number of reasons, especially during the subsequent code modification. Therefore, from time to time you need to return to this place of the program.
Now consider two such sets of regression testing statistics situations:
- Situations with a corrected defect, as well as situations with the addition of new functionality or cuts / deletions of old functionality. In this case, when a new version is released, the tester is obliged to check the defect (s) for correctness of the correction and run the entire set of test cases to ensure that other areas of functionality are not affected.
- Situations with the release of the new version, even if there are no “uncorrected” defects in the system and no new functionality has been added or the old functionality has been reduced or removed. In this case, the tester is obliged to drive the entire set of test cases to ensure that the system is operational and meets the requirements of the customer.
When conducting regression testing, often regression testing service uses automated tests that are run on test servers immediately after the deployment of a new intermediate version of the application, as well as after rolling out a new version on the production server.