Change Related Testing

Changes are made to the system in 3 cases:

To correct a defect
When new functionality is added
Existing functionality is changed

Testing is done to confirm that changes have corrected the defects or that new functionality has been implemented correctly. Also, testing ensures that changes have not caused unforeseen adverse effects.

Change Related Testing Type

Change-related testing is of two types:

1. Confirmation testing

Once the defect is fixed, the new version of the software is tested again with a re-execution of failed test cases. The software may also be tested with new tests to cover changes needed to fix the defect. At the very least, the steps to reproduce the failure(s) caused by the defect must be re-executed on the new software version. A confirmation test aims to confirm whether the original defect has been successfully fixed. Confirmation testing is also known as retesting.

2. Regression Testing

It is likely that a modification made in one piece of the code, whether to fix a defect or another type of change, may accidentally impact the behavior of other parts of the code, whether within the same component, in other components of the same system, or even in other systems. Changes may include environmental changes, database changes, operating system changes, software updates, software upgrades, or migration. Such unintended side effects are called regressions. Regression testing involves running tests to detect such unintended side effects.

Confirmation and Regression testing are performed at all test levels.

Change-Related Testing in Agile

Change-related testing is required in Iterative and Incremental development lifecycles like Agile, where code is frequently changed during the addition of new functionality, change to existing functionality, or code refactoring. Due to the evolving nature of the system, confirmation and regression testing are very important.

Regression test suites are run many times and generally evolve slowly, so regression testing is a strong candidate for automation. Automation of these tests should start early in the project.

Change-related testing and automation are relevant to many domains, including E-Commerce, Banking, Education, Travel, and Insurance. It also applies to the Internet of Things systems where individual objects (e.g., devices) are frequently updated or replaced.