# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://testplace.gitbook.io/tutorials/manual-testing/manual-testing-tutorial/retesting.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.