Bug life cycle is also known as Defect life cycle. In Software Development process, the bug has a life cycle. The bug should go through the life cycle to be closed
What is a Software Bug?
Software bug can be defined as the abnormal behavior of the software. Bug starts when the defect is establish and ends when a defect is locked, after confirming it is not reproduced.
Diagram :
The different states of a bug in the bug life cycle are as follows:
New: When a tester finds a new defect. He should provide a proper Defect document to the Development team to reproduce and fix the defect. In this state, the status of the defect posted by tester is “New”
Assigned: Defects which are in the status of New will be approved (if valid) and assigned to the development team by Test Lead/Project Lead/Project Manager. Once the defect is assigned then the status of the bug changes to “Assigned”
Open: The development team starts analyzing and works on the defect fix
Fixed: When a developer makes the necessary code change and verifies the change, then the status of the bug will be changed as “Fixed” and the bug is passed to the testing team.
Test: If the status is “Test”, it means the defect is fixed and ready to do test whether it is fixed or not.
Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is “verified.”
Closed: After verified the fix, if the bug is no longer exits then the status of bug will be assigned as “Closed.”
Reopen: If the defect remains same after the retest, then the tester posts the defect using defect retesting document and changes the status to “Reopen”. Again the bug goes through the life cycle to be fixed.
Duplicate: If the defect is repeated twice or the defect corresponds the same concept of the bug, the status is changed to “duplicate” by the development team.
Deferred: In some cases, Project Manager/Lead may set the bug status as deferred.
If the bug found during end of release and the bug is minor or not important to fix immediately
If the bug is not related to current build
If it is expected to get fixed in the next release
Customer is thinking to change the requirement
In such cases the status will be changed as “deferred” and it will be fixed in the next release.
Rejected: If the system is working according to specifications and bug is just due to some misinterpretation (such as referring to old requirements or extra features) then Team lead or developers can mark such bugs as “Rejected”
Some other statuses are:
Cannot be fixed: Technology not supporting, Root of the product issue, Cost of fixing bug is more
Not Reproducible: Platform mismatch, improper defect document, data mismatch, build mismatch, inconsistent defects
Need more information: If a developer is unable to reproduce the bug as per the steps provided by a tester then the developer can change the status as “Need more information’. In this case, the tester needs to add detailed reproducing steps and assign bug back to the development team for a fix. This won’t happen if the tester writes a good defect document.
This is all about Bug Life Cycle / Defect Life Cycle. Some companies use these bug id’s in RTM to map with the test cases.