Defect Life Cycle / Bug Life Cycle

The Defect Life Cycle, also known as the Bug Life Cycle, describes the different stages a defect goes through from the time it is identified until it is finally closed.

It helps the testing and development teams track defects in an organized way and makes it clear who is responsible for the defect at each stage. The exact statuses can vary between teams and tools, but the overall process is similar.

Common Defect Life Cycle

New → Assigned → Open → Fixed → Retest → Verified → Closed

Some additional statuses may be used depending on the situation.

1. New

The tester discovers a problem and reports it as a new defect.

The report should normally include enough information for the team to understand and reproduce the issue.

Example:
A tester enters valid login credentials, but the application displays an error message instead of logging the user in.

2. Assigned

The defect is assigned to the appropriate developer or team for investigation and resolution.

3. Open

The developer reviews the defect and starts investigating the cause of the problem.

The defect may remain in this state while the developer works on a solution.

4. Fixed

The developer makes a change intended to resolve the reported issue and provides the updated build or version for testing.

Important: A defect marked as "Fixed" does not automatically mean that the issue has been resolved successfully. It still needs to be tested.

5. Retest

The tester tests the specific defect again using the relevant steps and test data.

The tester checks whether the reported problem has actually been resolved.

6. Verified

If the tester confirms that the defect has been fixed correctly, the defect can be marked as verified.

The tester may also perform related regression testing to check whether the fix has affected other functionality.

7. Closed

Once the fix has been verified and the required conditions are satisfied, the defect is closed.

Other Possible Defect Statuses

Depending on the project, a defect may also have statuses such as:

• Reopened – The issue still exists or has appeared again after being marked as fixed.

• Rejected – The reported issue is determined not to be a valid defect.

• Duplicate – The same issue has already been reported.

• Deferred – The team decides to address the issue at a later time.

• Won't Fix – The team decides not to fix the issue.

• Cannot Reproduce – The team cannot reproduce the reported behavior with the available information.

Example

Suppose a tester finds that clicking "Submit Order" does nothing after entering valid checkout information.

The defect could move through the following process:

New → Tester reports the issue
↓
Assigned → Developer receives the defect
↓
Open → Developer investigates the problem
↓
Fixed → Developer provides a fix
↓
Retest → Tester checks the issue again
↓
Verified → Tester confirms the fix works
↓
Closed → Defect is completed

If the issue still exists during retesting, the tester can reopen the defect and provide updated evidence.

The Defect Life Cycle provides a clear and traceable process for managing bugs. It helps ensure that reported issues are properly investigated, fixed, retested, and closed rather than being lost or marked as resolved without verification.