Testplace tutorials
  • Quality Assurance 101
  • Manual Testing
    • Manual Testing Tutorial
      • What is Software Testing?
      • Software Development Life Cycle
      • Software Testing Life Cycle
      • Types of Software Testing
      • Levels of Testing
      • Automation Vs Manual Testing
      • Black Box & White Box Testing
      • Smoke & Sanity Testing
      • Regression Testing
      • Retesting
      • Regression vs Retesting
      • Entry And Exit Criteria
      • Test Scenario vs Test Case
      • Manual Testing Methods
      • Verification and Validation
      • Test Strategy
      • Test Plan
      • Test Strategy vs Test Plan
      • Bug Report Template
      • Test metrics
      • Difference Between Defect Bug Error And Failure
      • Write Good Bug Report
      • Principles of Software Testing
      • Black Box Test Design Techniques
      • Equivalence Partitioning Testing Technique
      • Boundary Value Analysis Testing Technique
      • Decision Table Test Design Technique
      • State Transition Test Design Technique
      • Severity Vs Priority
Powered by GitBook
On this page

Was this helpful?

  1. Manual Testing
  2. Manual Testing Tutorial

Retesting

What is Retesting?

Retesting : To ensure that the defects which were found and posted in the earlier build were fixed or not in the current build.

Retesting is running the previously failed test cases again on the new software to verify whether the defects posted earlier are fixed or not.

In simple words, Retesting is testing a specific bug after it was fixed.

Example: Say, Build 1.0 was released. While testing the Build 1.0, Test team found some defects (example, Defect Id 1.0.1 and Defect Id 1.0.2) and posted. The test team tests the defects 1.0.1 and 1.0.2 in the Build 1.1 (only if these two defects are mentioned in the Release Note of the Build 1.1) to make sure whether the defects are fixed or not.

Process: As per the Bug Life Cycle, once a tester found a bug, the bug is reported to the Development Team. The status of Bug should be “New”. The Development Team may accept or reject the bug. If the development team accepts the bug then they do fix it and release it in the next release. The status of the bug will be “Ready For QA”. Now the tester verifies the bug to find out whether it is resolved or not. This testing is known as retesting. Retesting is a planned testing. We do use same test cases with same test data which we used in the earlier build. If the bug is not found then we do change the status of the bug as “Fixed” else we do change the status as “Not Fixed” and send a Defect Retesting Document to the development team.

When Do We Do Re-testing:

1. When there is a particular bug fix specified in the Release Note: Once the development team releases the new build, then the test team has to test the already posted bugs to make sure that the bugs are fixed or not.

2. When a Bug is rejected: At times, development team refuses few bugs which were raised by the testers and mention the status of the bug as Not Reproducible. In this case, the testers need to retest the same issue to let the developers know that the issue is valid and reproducible.

To avoid this scenario, we need to write a good bug report. Here is a post on how to write a good bug report.

3. When a Client calls for a retesting: At times, the Client may request us to do the test again to gain the confidence on the quality of the product. In this case, test teams do test the product again.

A product should never be released after modification has been done to the code with just retesting the bug fixes, we need to do Regression Testing too.

PreviousRegression TestingNextRegression vs Retesting

Last updated 5 years ago

Was this helpful?