Skip to main content

Bug Life Cycle Or Defect Life Cycle In Testing

Definition

The Bug Life Cycleis the sequence of stages that a defect goes through from the time it is identified to the time it is resolved.

info

The Defect Life Cycle, also known as the Bug Life Cycle.

The Defect Life Cycle typically includes the following stages -

  • New: This is the initial stage of the Defect Life Cycle where a new defect is identified by a tester during the testing process.

  • Open: At this stage, the defect is reviewed by the development team to verify whether it is a genuine issue that needs to be addressed or if it should be rejected or deferred.

  • Assigned: If the defect is confirmed to be a genuine issue, it is assigned to a developer who is responsible for fixing it.

  • Rejected: If the development team / developer determines that the reported issue is not a genuine defect or not relevant to the current development cycle, they may reject the defect and close it without further action.

  • Deferred: If the development team/ developer decides to postpone the fix for a later release or sprint, they may defer the defect and prioritize it for future development cycles.

  • Fixed: Once the developer has fixed the defect, they mark it as "Fixed" and submit it for retesting.

  • Re-Open: If the tester finds that the defect is still present after retesting, they reopen it and send it back to the developer for further investigation.

  • Verified: If the tester finds that the defect has been fixed, they verify that the issue has been resolved and mark the defect as "Verified."

  • Closed: Finally, once the defect is verified and the fix is confirmed, the defect is marked as "Closed."

caution

Generally in practice, we do not follow the Open and Verified stage in the Bug Life Cycle.

Some important interview Questions-​

1. Does your team follow a specific Bug Life Cycle? If not, could you explain why?

Yes but not completely, I have seen in practice, the Open and Verified stages of the Defect Life Cycle may not be followed. For example, if a tester reports a bug, it may be considered valid without requiring additional verification by the team lead, and can be directly assigned to a developer. Similarly, once a bug is fixed, it can be closed without explicitly verifying the fix, depending on the organization's development processes and practices."

2. What will you do when a developer differed the bug?

If a developer defers a bug, it indicates that they acknowledge it as a valid issue but have determined that it does not require immediate attention or that it can be addressed in a later development cycle. The tester may not be able to take any further action.

In this case, it is important for the development team to document the reason for deferring the bug and communicate it to all relevant stakeholders to ensure transparency and understanding of the issue's status and priority.

What will you do when developer rejected your bug?

Here there may be two conditions-

  1. If a developer rejects a bug, the tester should review the bug again and verify whether it is a valid issue as per the project requirements. If it is not a valid bug, the tester should close the bug with a proper comment explaining the reason.
  2. If the tester determines that the bug is still a valid issue, they should reopen the bug and provide additional details such as updated requirements, scenarios, and screenshot. If the bug is rejected again, the tester can call for a meeting with the developer, developer lead, tester's lead, and manager to discuss the issue. The tester can demonstrate the bug and provide all relevant information for the manager to decide on the next steps