ISTQB CTFL v4.0: Mastering Change-Related Testing

Change-related testing occurs after software modifications. It includes Confirmation Testing (re-running failed tests to verify a defect fix) and Regression Testing (running test suites to ensure new changes haven't inadvertently broken existing, previously working functionality).

Why Do We Need Change-Related Testing?

Software is rarely static. It undergoes constant modification to fix defects, add new features, improve performance, or adapt to changing environments. However, every time code is modified, there is a risk. The change might fail to solve the original problem, or worse, it might introduce new defects into previously working areas of the application. Change-related testing is specifically designed to mitigate these risks.

The ISTQB CTFL v4.0 syllabus categorizes change-related testing into two distinct but complementary activities: confirmation testing and regression testing. These activities are essential safeguards throughout the software development lifecycle (SDLC) and during software maintenance. Without rigorous change-related testing, product quality degrades rapidly as modifications accumulate.

Change-related testing can be applied at all test levels and for all test types (functional, non-functional, white-box). Whether a developer is fixing a unit test or a release team is validating a major system update, confirming fixes and checking for regression are fundamental steps in ensuring continuous software stability.

What is Confirmation Testing (Re-testing)?

Confirmation testing, also known as re-testing, is executed specifically when a defect has been identified, reported, and subsequently fixed by the development team. The sole objective of confirmation testing is to confirm that the original defect has indeed been successfully eliminated and the specific feature now works as intended.

To perform confirmation testing correctly, the tester must re-execute the exact same test steps, using the exact same data and operating in the exact same environment that originally caused the test to fail. If the test passes, the defect is considered resolved and can be closed. If the test fails again, the fix was ineffective, and the defect must be returned to the developer for further investigation.

Confirmation testing is a highly targeted activity. It does not attempt to find new defects; it only validates the specific repair. Because it involves repeating known steps, confirmation tests are prime candidates for automation, especially if the fix requires multiple iterations before it is fully resolved.

How Does Regression Testing Protect Quality?

While confirmation testing checks if a specific fix worked, regression testing checks if that fix (or any other change) caused collateral damage. Modern software systems are incredibly complex and interconnected. A minor code change in one module can easily have unintended consequences, breaking functionality in a seemingly unrelated part of the application. These unintended consequences are called regressions.

The objective of regression testing is to verify that modifications have not caused adverse side effects in unchanged areas of the software. To achieve this, testers execute a regression test suite—a collection of previously passed test cases that cover the core, critical functionalities of the system. If a test in the regression suite fails after a change, it indicates that a regression defect has been introduced.

Regression testing is crucial whenever the software changes, whether due to bug fixes, feature additions, environmental upgrades (like an OS update), or structural refactoring. It provides the confidence needed to release new versions without fear of disrupting existing users.

Why is Test Automation Critical for Regression Testing?

Regression test suites tend to grow over time. As new features are added to the software, new test cases are created and eventually added to the regression suite. Manually executing a massive regression suite every time a developer makes a small change is time-consuming, expensive, and highly prone to human error due to the repetitive nature of the task.

For this reason, regression testing is one of the most common and valuable areas for test automation. Automated regression suites can be executed quickly, consistently, and frequently—often running nightly or triggered automatically upon every code commit as part of a Continuous Integration/Continuous Deployment (CI/CD) pipeline. This rapid feedback loop allows developers to identify and fix regression defects almost immediately after they are introduced.

While maintaining an automated regression suite requires effort and technical skill, the return on investment is significant. It frees up manual testers to focus on exploratory testing and evaluating complex new features, rather than mindlessly repeating old tests.

How Do You Manage Regression Test Suites?

Managing a regression test suite is an ongoing process. A suite that is too small will miss critical regressions, while a suite that is too large will take too long to run and become difficult to maintain. Effective regression suite management involves continuous review and optimization to balance coverage with execution speed.

When a change occurs, testers do not necessarily run the entire suite. They can select a subset of tests based on Impact Analysis—understanding which modules are most likely affected by the specific code change. This targeted approach is called selective regression testing. Additionally, older test cases may become obsolete if the features they test are modified or removed; these tests must be updated or retired.

Prioritization is also key. High-priority regression tests cover critical business flows and frequently used features; these should be run frequently. Lower-priority tests, which cover edge cases or rarely used features, might be run less often. By actively managing the suite, teams ensure that regression testing remains an efficient and effective safety net.

❓ Frequently Asked Questions