Testing 101 – Regression Test, Re-Test and Test Automation

Often similar terminologies in testing can lead to misunderstandings and confusion. In our testing 101 today we would like to address regression testing and re-testing and their roles in test automation.

Both sound similar, they have though completely different roles in software quality assurance.

Regression test

Let´s take a look at regression test at first. The regression test in quality assurance is in charge of making sure that system functionalities still work in the same way as before, after a system change has been applied.

It verifies thus for us the unaffected functionality of the system.

When we carry out an update in a system, in most of the cases it surely shouldn´t change all functionalities in our system, but only change certain process flows or add new functionalities.

The large rest of our system which should remain unchanged is the focus of the so-called regression tests. They should ensure that the changes made in the system have not led to too many unwanted behavior changes in the rest of the system.

E.g.: Our web shop is enhanced by a product configurator. By means of this configurator, the customers should be able to personalize variations of a product to their own ideas. Log in, payment process, entry of the reference data, contact form, etc. will remain unaffected (or should rather remain unaffected).

We verify with the aid of the regression test, or to put it simply in a before and after test, if our system behaves in the same way in those areas which shouldn´t be changed and if no undesired behavior changes have occurred in the system.

Re-test

The re-test, often mistaken for regression test, has a fully different role in our quality assurance. It comes into play when we have already found operating faults.

Its task is to verify whether an error which has occurred in a test cycle has after the correction by the developer been fixed in another test iteration.

E.g.: When we find an operating fault in our system, then we report it in terms of an error report. Afterwards it is fixed by developers and an update is done on the system in order to enable us to test the functionality anew – the re-test.

In the course of this recent test we verify whether our detected error could be corrected through debugging by the developer – this is the task of re-tests.

In re-testing it is often discussed which test cases should now be run again after the operating fault has been detected:

• Only the one test case in which the error has been located?
• Test cases which concern the affected process and thus the “surrounding area”?
• Or do we grasp further to make sure?

Regression test and re-test with test automation support

This question can easily be answered in times of test automation. In this case we would like to digress a little from the classical testing school and say: When no additional tester´s effort is required, then it is quite legitimate to test the surrounding areas of the detected error effect intensely and thus to verify potential side effects of the debugging.

Very often error effects disguise other errors: the disguised or up to that point the hidden error occurs just as the disguised error is fixed.

It can also happen that the correction of an error or the coding that fixes our error leads to a resultant problem, the so-called side effect.

Both these cases are often located in the circuit of the initial malfunction, could however indeed occur in a broader area.

Area of application of test automation

The classical areas of application for test automation cover exactly the previously discussed regression tests. In this context, our most important processes can be proved through test automation with a test coverage and the desired system behavior can be ensured as often as desired, at any time.

If we add additional functionalities to our system, these new functionalities will then be taken over in our regression test case set by creating new test cases.

If you are interested in our suxxesso Tool Suite , then please contact us.