Regression testing and progression testing

A very specific angle in determining the test varieties needed, is whether the team is testing newly created or changed software or whether they are testing parts of the software that should not have been changed. The terms relating to this are progression testing (for new software and changes), regression testing (to check if the unchanged software indeed works as before) and re-testing (to check if a fix for a previously found anomaly was indeed effective).


A regression test is a test aimed at verifying that all unchanged parts of a system still function correctly after the implementation of a change.


A progression test is a test of new or adapted parts of a system.


A re-test is to execute a previously failed test case to verify whether a problem has been properly fixed (also called confirmation test).

Team members must be aware of these three specific reasons for testing, even though these can often be tested in just one test scenario.

Since in DevOps work is done incrementally, the team will often make changes to existing software, which brings a great need for regression testing, every iteration again. Therefore, the regression tests are very good candidates to be automated and to be included in the automated integration and deployment process of the CI/CD pipeline.

When the sphere of testing is an end-to-end business process, it will be hard for an individual DevOps team to perform an end-to-end regression test. Therefore, an organization should choose to install a separate team that, on request of a DevOps team that made a change to the process, performs an end-to-end regression test.