tldr: Confirmation testing, also called re-testing, verifies that a specific bug fix actually fixed the bug. It is the narrow follow-up to a defect, not a broad regression check. Both are needed, and confusing them produces flaky test cycles.
What confirmation testing is for
A bug was found. Engineering claims the fix is in. Confirmation testing answers: did the fix actually fix it?
That sounds obvious. It is also the step teams skip most often. The fix gets merged, the ticket gets closed, and three weeks later a customer reports the same bug because the fix only handled part of the case.
Confirmation testing prevents that.
Confirmation vs regression
The two get confused constantly.
Confirmation testing. Tests that the specific bug is fixed. Narrow scope: typically one or two test cases targeting the exact reported scenario.
Regression testing. Tests that the fix did not break anything else. Broad scope: a suite of tests across the affected feature or the whole application.
Both are needed when a bug is fixed. Confirmation proves the fix worked. Regression proves the fix did not introduce new bugs.
How to run confirmation testing
Three steps.
1. Reproduce the bug on the unfixed build
This sounds obvious. Skip it and you have no baseline. If the bug cannot be reproduced before the fix, you cannot prove the fix worked.
This is also the moment to confirm the bug report is accurate. If the steps in the ticket do not actually reproduce the bug, the bug was misdiagnosed.
2. Apply the fix
Pull the build with the fix applied. Make sure it is actually the build you think it is: check the commit hash, version number, or feature flag state.
3. Repeat the original steps
Walk through the same scenario from the bug report. The bug should not reproduce. Capture evidence (screenshot, recording, log) for the ticket.
If the bug still reproduces, the fix did not work. Reopen the ticket with the new evidence.
What gets missed
A confirmed fix on the original scenario does not mean the underlying bug class is fully fixed.
Three patterns to test for:
Adjacent inputs. The bug was reported with input X. Test with X-1 and X+1. Often the underlying issue affects a range, not a specific value.
Adjacent flows. The bug was reported on flow A. The same bug class might exist on flow B. Quick check: does the same kind of input cause the same kind of failure elsewhere?
The bug class. If a bug was found because of unhandled null in field X, search the codebase for similar patterns: are other fields handling null correctly?
The first two are confirmation-adjacent. The third borders on regression. All three reduce repeat bugs.
Confirmation testing in CI
The bug should be turned into an automated test as part of the fix.
A working pattern: when an engineer fixes a bug, they add a test that fails on the unfixed code and passes on the fixed code. The test goes into the regular test suite. Future regressions get caught automatically.
Without this discipline, confirmation testing is a one-time activity. With it, every fixed bug becomes permanent regression coverage.
How AI testing fits
For UI bugs, AI testing platforms make this easy. Describe the failing scenario in plain language, run it on the unfixed build (it fails), run it on the fixed build (it passes). The test goes into the suite for ongoing regression.
Bug0 and the Passmark engine handle this without selectors or step definitions, which keeps the cost of adding tests low.
When to skip confirmation testing
Almost never. Even for trivial bugs, the cost of a five-minute confirmation is much lower than the cost of a re-reported bug.
The exceptions:
- Pure typo fixes (string changes, no code logic).
- Documentation-only updates.
- Fixes that delete dead code.
Anything that changes runtime behavior gets a confirmation test.
FAQs
Is confirmation testing the same as smoke testing?
No. Smoke testing checks the whole system fundamentally works. Confirmation testing checks one specific defect is fixed.
Who runs confirmation testing?
Whoever has the most context on the bug. Usually QA if QA reported it, engineering if it was an internal find.
What if the bug cannot be reproduced anymore?
Two possibilities. The fix worked. Or the bug requires conditions that no longer exist. Capture the steps you tried and document the outcome. Do not close the ticket without evidence.
How does confirmation testing relate to regression testing?
Confirmation is narrow (one bug). Regression is broad (everything else). Run both after a fix.
How does Bug0 help with confirmation testing?
Bug0 lets you describe the failing scenario in plain English, run it before and after the fix, and add it to your regression suite in the same step.