Re-Testing: Verifying That Defects Are Truly Fixed

Introduction to Re-Testing

Re-Testing is the process of executing the same test case again to verify that a previously reported defect has been fixed correctly. It focuses strictly on confirming the resolution of a specific issue. In simple terms, re-testing answers the question: is the reported bug really fixed?

Re-testing is a direct validation activity and forms a critical part of defect management.

Purpose of Re-Testing

The primary purpose of re-testing is to confirm that the defect fix works as expected. It ensures that the intended behavior has been restored and that the fix is complete rather than partial. Re-testing also prevents incorrect defect closure, which could lead to repeated failures later.

By validating each fix carefully, re-testing supports accurate defect tracking and quality assurance.

When Re-Testing Is Performed

Re-testing is performed after a defect is marked as fixed and a new build is made available for verification. It typically occurs before regression testing begins, since the specific fix must first be validated before checking its broader impact.

Re-testing is part of the defect verification cycle and continues until the issue is either confirmed as resolved or reopened.

Scope of Re-Testing

The scope of re-testing is narrow and specific. It involves executing the exact test case that originally failed, using the same test steps and test data. The goal is to compare the new result against the expected behavior defined earlier.

Re-testing does not involve checking related modules or validating side effects. That responsibility belongs to regression testing.

Re-Testing Compared to Regression Testing

Re-testing and regression testing are often confused, but they serve different purposes. Re-testing focuses on a specific defect fix and uses the same test case that failed previously. Regression testing focuses on ensuring that existing functionality continues to work after changes and uses different test cases covering broader areas.

Re-testing is mandatory for defect closure, while regression testing is strongly recommended to ensure stability.

Role of the Manual Tester

The manual tester re-executes the failed test case carefully and validates whether the issue is resolved. Based on the outcome, the tester updates the defect status to closed if fixed or reopens it if the problem persists. If the defect is reopened, clear evidence and steps must be provided.

Accurate documentation during re-testing maintains transparency and accountability in defect resolution.

A Practical Scenario

Consider a defect where the submit button does not respond. After the developer applies a fix, the tester re-executes the same steps that originally exposed the issue. If the button now works as expected, the defect is marked as closed. If the issue remains or behaves differently, the defect is reopened with updated evidence.

This direct validation ensures reliability in defect tracking.

Entry and Exit Considerations

Re-testing begins when a defect is marked as fixed and a new build is available. It concludes when the defect is verified as resolved or formally reopened for further correction.

These clear checkpoints ensure that fixes are validated methodically.

Common Mistakes

One common mistake is modifying the test case during re-testing, which reduces consistency. Another error is skipping re-testing and moving directly to regression testing, leaving defect resolution unverified. Using different test data may also produce misleading results.

Re-testing must remain controlled and consistent.

Interview Perspective

In interviews, re-testing is typically defined as executing the same test case again to verify that a defect has been fixed. A strong explanation emphasizes that it validates resolution rather than testing the entire application.

Key Takeaway

Re-Testing ensures that defect fixes are validated, not assumed. It provides confidence that reported issues are truly resolved before the product moves forward. Without re-testing, defect closure would rely on assumption rather than verification.