Work wisely, not hard – automation of regression tests

When we create an application we care about its stability and proper functioning. Equally important is the continuous
development of the project with new functionalities. However, regular updates in the software, in addition to new features, may bring new problems. Something that used to work before may not work now.

The solution to this problem is to regularly test not only the newly added functionalities, but also those previously tested. This is called regression testing. This action will allow us to detect and fix errors in our application in a much shorter time.

Regular testing of the entire project takes time. Some projects are so extensive that it could take us a lot of time to manually check all functionalities. In this situation, it is worth to deal with the automation of regression testing.

Automation allows us to regularly, quickly and easily test all the functions of our application. Thanks to the fact that they were once tested by a human being, we know the expected result and can write a program that will carry out the tests for us, then compare their result with the expected one. If we properly configure any tool to run the tests automatically (e.g. Jenkins), we can generate a report that will give us an overview of all new bugs in one place. This approach allows us to react quickly and fix the malfunction of our project.

Regression tests should be performed not only after implementation of changes in the project.
Regular testing will also allow us to detect errors in software stability as well as complex errors that are easy to overlook as a manual tester. Therefore, it is worth to perform them regardless of new version implementations. For example, periodically, or every time the server on which the system is rebooted.

What features should the proper automatic tests have?

• Stability – tests should be primarily stable. Repeated runs on the same version of our application should return similar results. In case of different results, it is more difficult for us to determine the type and origin of errors, so it will take us more time to find and fix defects.
• Test environment – should be as close as possible to the production environment. The greater the similarity, the greater the chance that errors will be detected at an earlier stage of testing.
• Credibility – it is important that the person working on the application receives a reliable result and can take appropriate action based on it. Our tests will become useless when we receive the answer that some functionality works correctly when in fact it does not.
• Reports – appropriate configuration of test reports allow us to focus all errors in one place, which makes it much easier to find and correct them.

Creating the right database of automated scripts can take a long time.
In addition, just like the application itself, these tests must be sustainable. This means that when making changes to the application, you also need to make appropriate corrections to the tests themselves.
It is worth remembering at the very beginning of scripting, so as not to waste more time applying patches in tests than in the application itself.

In addition, regression testing does not have to cover 100% of the application, but only its most important functionalities. Of course, it is worth adding more over time so that the test collection grows with the application and strive for full automation of the testing process.