2.2.3. Confirmation Testing and Regression Testing
Changes are typically made to a component or system to either enhance it by adding a new feature or to
fix it by removing a defect. Testing should then also include confirmation testing and regression testing.
Confirmation testing confirms that an original defect has been successfully fixed. Depending on the risk,
one can test the fixed version of the software in several ways, including:
• executing all test cases that previously have failed due to the defect, or, also by
• adding new tests to cover any changes that were needed to fix the defect
However, when time or money is short when fixing defects, confirmation testing might be restricted to
simply exercising the steps that should reproduce the failure caused by the defect and checking that the
failure does not occur.
Regression testing confirms that no adverse consequences have been caused by a change, including a
fix that has already been confirmation tested. These adverse consequences could affect the same
component where the change was made, other components in the same system, or even other
connected systems. Regression testing may not be restricted to the test object itself but can also be
related to the environment. It is advisable first to perform an impact analysis to optimize the extent of the
regression testing. Impact analysis shows which parts of the software could be affected.
Regression test suites are run many times and generally the number of regression test cases will
increase with each iteration or release, so regression testing is a strong candidate for automation.
Automation of these tests should start early in the project. Where CI is used, such as in DevOps (see
section 2.1.4), it is good practice to also include automated regression tests. Depending on the situation,
this may include regression tests on different levels.
Confirmation testing and/or regression testing for the test object are needed on all test levels if defects
are fixed and/or changes are made on these test levels.