In general terms, we think of regression testing as:
-retesting of a recently modified software to ensure that any bugs that have been fixed are actually working as designed
-no other previously working functionality has failed
-newly added features have not introduced bugs.
Therefore, we must agree that any change in the code of an application, however small and harmless, can have significant negative consequences.
A small change can “break” parts of the code that previously worked which didn’t have any relation to the modification we have made. And of course you can reintroduce bugs that have already been solved.
When we do regression tests, we should be checking that the code we have modified behaves as required, and that the change has not caused problems in other areas of the software, which worked correctly the last time it was tested.
By re-executing the tests which previously detected errors, we can be more certain that the new changes do not cause a regression, that is, they do not cause components that have previously worked to stop working. These regression tests can be done manually, but ZeuZ’s scriptless test automation makes it really easy to automate them and run them frequently. Regression tests usually have an important role in the process of CI/CD and are usually launched by continuous integration solutions like TeamCity and Jenkins (both of which ZeuZ test automation framework supports).
How are regression tests done?
Regression tests do not need to be written from scratch, but rather can be created from tests that we have developed during development.
The idea is that every time you modify the source code, you run a selection of relevant tests that you already had to test for. Functional tests, unit tests, integration tests (anything you have verified during the development process that certain software components work as they should) can act as regression tests.
For example, we could take advantage of JUnit unit tests performed by developers, and include them as automated regression tests.
In addition, as the project progresses, the battery of regression tests can become larger and larger and time consuming. Even tests that we had previously included as regression tests may no longer apply, or may not be as relevant as the software evolves.
There may come a point where running all the battery of tests we already have is unfeasible.
Therefore, we have to be careful and select only tests that will act as regression tests. It is of no use to have a battery of automatic regression tests that run from time to time, if they really do not prove anything, and don’t test for errors that have been made before.
When we finish testing the software, we will have to perform an impact analysis and determine which tests are the most relevant, which will really give us some value if they run periodically, and include them as regression tests.
We must also note that the battery of regression tests does not remain the same throughout the development. As the software evolves, we will have to adjusts and often discard those that no longer give us value.
In summary, the concept of regression tests does not imply that they have to be automated, just that it is something that tends to be performed often and should be execute frequently. And as always, we at ZeuZ believe that you should be deploying a wide array of testing, including manual and exploratory testing. For more information how ZeuZ scriptless test automation can help with regression, functional, smoke, UI/usability, and stress/load testing, contact us or check out our demos.