QA glossary
What is confirmation testing?
Confirmation testing is running the test again after a bug fix to check that the original defect is really gone. It is often called re-testing. It answers one question, "is this bug fixed?", and is followed by regression testing, which asks whether the fix broke anything else.
An example from QA practice
A tester reports that the checkout total ignores a discount code on orders over 500. The developer fixes it and marks the bug as fixed. The tester repeats the exact steps from the report, with the same code and the same basket, and sees the discount applied. Because the fix touched the price calculation, they also add a test at exactly 500 and run the checkout regression suite. Only then is the bug closed.
Confirmation testing versus regression testing
- Confirmation testing checks that the original defect has been fixed, by re-running the tests that failed or adding new tests for the change.
- Regression testing checks that the change, including the fix, has not caused problems elsewhere in the same component, other components or connected systems.
- Order: confirm first, then run regression, because a fix that does not work makes the wider run a waste.
This is the distinction in the ISTQB Foundation Level syllabus (CTFL v4.0.1, section 2.2.3), which adds that when time is short, confirmation testing may be limited to the steps that reproduce the failure.
How BetterQA does it
In BugBoard a bug moves from fixed to verified only when a tester confirms the fix, and only then to closed. Our engineers re-run the steps from the original report, the reason every report carries exact steps to reproduce, and then pick the regression tests the change could affect. A fix marked done by the developer alone is not counted as verified.