The Bug Life Cycle is a vital part of the whole defect management process. In this article I have described the various states of a bug from its opening to closure. Also How it gets changed from one state to another.
Description of the Bug Life Cycle States:
Submitted - The test team member enters a defect into the defect management tool where it is assigned to the designated development leads. A development lead point is defined as a person on the development team who is designated in Defect management Tool as the contact for defects for a given application.
Assigned - It is the development team’s responsibility to assign the Dev Lead in Defect tracking tool. The development focal point assigns the defect to a developer.
Opened - The developer acknowledges the defect and begins actively working on a solution.
Resolved - The developer implements a fix and is responsible for providing feedback to the tester regarding details of the defect and the solution. The developer marks the defect as resolved and the fix is ready to be built and deployed.
Ready for Test - The deployment team creates a build that incorporates the defect fix and deploys this build to the System Test Environment. The deployment team will then mark the defect as Ready for Retest, and assign the defect back to the reporting tester. In addition, the Build # containing the fix is tracked in Defect tracking tool.
The tester re-tests the defect.
The Closed - If the defect is fixed, the tester verifies that the developer added comments about the problem and resolution before closing the defect. Once comments are added, the tester closes the defect.
Resubmitted – When a defect that was once Closed, but the issue reoccurs, the defect can be placed into the Resubmitted state and the defect assigned to the Development Lead for assignment.
Postponed – When a defect is valid, but the defect functionality is out of scope for this release, the State of the defect will be marked as Postponed. This state is restricted to only members of the Lead Group. Once a defect is determined to be postponed, the leader must provide details that support the discussion to postpone this defect to a later release.
Duplicate – When a defect is valid, but the issue has been reported in another defect record, the subsequent defect can be marked as duplicate.
Subscribe to this comment's feed
| < Prev |
|---|
