Confirmation Testing

Example usage

A test case for the login function failed because a password-validation defect was found. The developer fixes the defect. Re-testing then runs that same test case again to verify the corrective action worked: the login now succeeds, and the previously failing test case passes. Note that re-testing only re-runs the tests that failed — verifying unchanged functionality is regression testing.

FAQ

What is the difference between re-testing and regression testing? Re-testing runs test cases that failed the last time they were run, to verify that corrective actions succeeded. Regression testing tests previously tested, unchanged functionality to ensure the change introduced no new defects. Both are needed after a fix.

Is re-testing also called confirmation testing? The ISTQB glossary treats them as related: confirmation testing is the same concept of verifying that a defect is fixed, and both contrast with regression testing. The terms are used interchangeably in many syllabi.

When is re-testing done? After a defect fix, before the fix is accepted. It is usually followed by regression testing of the surrounding functionality.

Can re-testing be automated? Yes. The previously failing automated test case is re-run — ideally as part of a CI pipeline that also runs the regression suite.

Related terms

• confirmation testing — verifying a defect is actually fixed
• regression testing — testing unchanged functionality after a change
• defect — what the corrective action addresses
• test case — the unit that is re-run
• debugging — locating and fixing the defect before re-testing
• failure — the observed behavior that made the test fail