Testers conduct confirmation testing when development returns bug fixes from previous testing rounds. Confirmation testing, also known as retesting, should eventually confirm that all bug fixes are successful.
If confirmation testing confirms that the applied fix works because the product performs as expected, the defect is closed. If the issue remains, it is reopened and reassigned to the developers with some comments by the testers.
The whole process of checking and confirming the fix is known as confirmation testing. It requires running the same steps, using the same data set, and in the same environment as when the bug was first encountered.
When to perform confirmation testing?
Unlike all other types of testing, where the primary objective is to find defects, confirmation testing aims to ensure that all reported faults are addressed and the functionality works as expected. Let’s look at when to perform confirmation testing during the Software Testing Life Cycle.
- When a bug is fixed – As the name implies, this kind of testing confirms when a requested update is complete. In our case, the update is a bug fix. Run confirmation testing each time a bug is fixed to verify the changes are as expected.
- Non-reproducible bugs, or when more information is needed – There are instances when testers cannot recreate a bug, or the developers need additional information to be able to do so. In such cases, testers conduct confirmation testing to validate whether the bug still exists or was somehow auto-resolved. After rechecking, they share extra information with developers or mark the bug closed to indicate no more fixes are needed.
- When a bug is rejected – Sometimes, a bug is dismissed because the section works as intended. In such events, the bug reporter reviews the defect again to eliminate misunderstandings. If they assess the bug as valid, they add additional information before returning it to developers.
- Before regression testing – Retesting validates each fixed bug and must be completed before running any regression tests. The regression effort depends on the bug fixes since regression requires running checks around that bug to ensure the fix did not impact other functionalities.
More about confirmation testing
We have established that confirmation testing is an essential step, often conducted several times during the overall testing process. Confirmation testing differs from all other testing types for a few reasons.
- Limited scope – Confirmation testing validates fixed bugs, so it has limited scope and is easy to test. It does not require highly specialized skills since all that’s needed is to rerun the steps mentioned in the bug.
- Confirmation testing is manual – Each bug requires individual intervention for validation and confirmation. Therefore, confirmation testing is entirely manual.
- Retesting is a repetitive task – Every system change needs testing, whether a fix or a new development. All new products have a test plan for running tests, including unit, integration, and functional. All fixes actioned by the test results need validation. Unavoidably, confirmation testing is repeat work that sometimes requires testing the same fix repeatedly until it is fully resolved. This involves running the same tests on the same environment multiple times.
- No need for test cases – Little planning is required to retest because there’s no need for test case creation or other documentation. It is performed as and when needed, depending on bugs logged and fixes made. In-depth application knowledge is unnecessary, so even new team members can test. All that’s required are the steps to verify and the final expected outcome to confirm the behavior.
- It does not reveal new bugs – The primary purpose of testing is to find bugs. As we have seen, the objective of this type of testing is not bug finding but to work on the bug validation after the bug fix. It confirms the expected behavior after the update.
Conclusion
In software development, skipping some tests under specific circumstances is okay, but no software testing life cycle can be called complete without confirmation testing. A dedicated QA team may not always do confirmation testing, but it remains integral to any development process. After making any code change, developers can run the retests to confirm that the change aligns with the expected output.
