What is Retesting? A Complete Guide

Retesting is the process of verifying that an old defect has been fixed and the affected features now work properly. It ensures that the same bug does not persist after a fix.

Key Takeaways:

• Retesting ensures that a previously failed test case now works after a defect fix, preventing repeat issues.
• Retesting happens before regression testing. It focuses only on the defect area to verify the fix, while regression testing checks the entire system.
• Manual execution is common for retesting.

Example of Retesting

Here is the chain of events that happen in a retesting scenario:

1. An e-commerce website allows customers to add items to their shopping cart.
2. A QA tester discovers a bug: when users remove an item from the cart, the cart total does not update correctly. Instead, the removed item's price still contributes to the final cost.
3. They document everything and report the bug to the dev team, who traced the issue to a JavaScript failing to trigger the price re-calculation.
4. The developer fixes the bug. They deployed it to the staging environment for verification.
5. The QA tester then re-executes the same test steps that originally caused the issue. This is the retesting part.
6. There are 3 scenarios: the cart now updates the price correctly, or the bug still persists, or an entirely new issue is identified (this is when the tester logs a new defect for additional fix).

Characteristics of Retesting

• Retesting is usually done manually. It focuses on a highly specific test case, and since the system is usually changed after the bug fix, the automation test case may not work as properly.
• Retesting follows a structured and planned approach. Previously failed test cases are systematically re-executed against a checklist of identified issues. This is why retesting is sometimes called confirmation testing or planned testing.
• Retesting takes higher priority than regression testing since it must be completed first. QA teams must confirm that a defect has been fixed before they move on to regression testing to verify that the fix did not impact other functionalities.
• Retesting is limited to the specific area where the defect originally occurred. It does not extend beyond the affected module or feature.

Why is Retesting Necessary?

• Ensures bug fixes are successful.
• Prevents repeat defects from affecting end-users.
• Helps developers validate their fixes.
• Required in critical applications where defects can cause significant issues.

When Should Retesting Be Done?

• After developers have fixed a reported defect.
• Before moving to regression testing.
• As part of the software release cycle.
• During critical updates and hotfixes

Retesting vs Regression Testing

Retesting focuses on checking if a specific defect works properly after it is fixed. Regression testing checks the entire system to see if code updates create new defects.

Here is a simple table to compare retesting vs. regression testing:

Can Retesting and Regression Testing Be Done Together?

Yes, retesting and regression testing can be done together as part of the software testing lifecycle. Here's how it works:

1. Retesting First: When a defect is fixed, retesting is performed to verify that the fix works as expected.
2. Regression Testing Next: After retesting, regression testing is conducted to ensure that the fix hasn’t introduced new issues elsewhere in the application.
3. Parallel Execution (CI/CD): In continuous testing environments, automated regression tests can run alongside manual or automated retesting to improve efficiency.

Retesting is defect-specific, while regression testing ensures system-wide stability. Together, they provide a comprehensive view on software quality.

The Retesting Process

1. Test case selection

To begin retesting, testers need to find the failed test case for the specific defect that will be retested.

They have to determine if:

• This test case can be reused, which is when:
  • The defect fix does not alter the original test scenario.
  • The test steps, expected results, and data remain valid.
  • The failure was due to a bug in the system, not an issue with the test itself.
• This test case must be adjusted, which is when:
  • The fix changes the workflow, UI, or logic of the affected area.
  • New edge cases or scenarios need to be considered.
  • The test case had incorrect assumptions or invalid steps before the defect was reported.

If the test case was an automation script, it must also be updated.

2. Test execution

After that, testers start to execute the selected test cases under the same conditions as the initial failure. This is important because we want to completely remove any external factors that can tamper with the retest result.

After that, compare actual vs. expected output to see if the bug is actually fixed.

3. Analyze retest results

There are three scenarios:

✅ Pass: The defect is resolved; functionality works as expected.
❌ Fail: The defect persists or reoccurs, requiring further fixes.
⚠️ New Issues Identified: Code changes introduced unintended side effects.

In all scenarios, you should:

• Document test results with screenshots, logs, or video recordings for clear reporting.
• Communicate findings with the development team for resolution.

Read More: What is Test Reporting? How To Build a Good Test Report?

Retesting Completion Criteria

• All defect-related test cases pass without issues.
• No new defects are introduced due to the fix.
• The system is stable and ready for regression testing.

Best Practices of Retesting

• Always prioritize defects based on severity and impact.
• Use fresh test data to avoid false positives.
• Maintain detailed defect documentation for accurate verification.
• Automate repetitive retests when possible.
• Perform exploratory testing after retesting to uncover hidden issues.
• Collaborate closely with developers to improve fix quality.

Conclusion

Retesting is a critical step in software quality assurance to ensure that fixed defects no longer persist and that the application functions as expected.

Regression testing and retesting are two important parts of testing. Automating regression tests with a tool like Katalon Studio allows teams to:

• Run comprehensive test suites
• Improve test coverage
• Integrate with CI/CD pipelines for continuous software quality
  
  

Learn more about Katalon's features