In this post, we’ll take you through everything you need to know about Bug Life Cycle (Defect Life Cycle). In the earlier post, we have learned what is Software Testing, the Software Life Cycles such as SDLC and STLC.
We’ll start with a Definition of the Bug Life Cycle, and different states of the defect life cycle.
Definition Bug Life Cycle
The bug life cycle is also known as the Defect life cycle. In the Software Development Process, the bug has a life cycle. The bug should go through the life cycle to be closed. The bug life cycle varies depends upon the tools (QC, JIRA, etc.,) used, and the process followed in the organization.
What is a Software Bug?
A software bug can be defined as the abnormal behavior of the software. The bug starts when the defect is found and ends when a defect is closed, after ensuring it is not reproduced.
Defect Life Cycle – Video Tutorial
Check the below video to see a detailed explanation of “Bug Life Cycle / Defect Life Cycle”
Please be patient. The video will load in some time.
If you liked this video, then please subscribe to our YouTube Channel for more video tutorials.
Defect Life Cycle States
The different states of a bug in the bug life cycle are as follows:
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 the tester is “New”
Defects that 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”
The development team starts analyzing and works on the defect fix
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.
If the status is “Test”, it means the defect is fixed and ready to do test whether it is fixed or not.
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.”
After verified the fix, if the bug is no longer exits then the status of the bug will be assigned as “Closed.”
If the defect remains the same after the retest, then the tester posts the defect using the defect retesting document and changes the status to “Reopen”. Again the bug goes through the life cycle to be fixed.
If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate” by the development team.
In some cases, the Project Manager/Lead may set the bug status as deferred.
- If the bug found during the end of the release and the bug is minor or not important to fix immediately.
- If the bug is not related to the current build.
- If it is expected to get fixed in the next release.
- The 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.
If the system is working according to specifications and the bug is just due to some misinterpretation (such as referring to old requirements or extra features) then the 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 a bug is more
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 bugs back to the development team for a fix. This won’t happen if the tester writes a good defect document.
This is all about the Bug Life Cycle / Defect Life Cycle. Some companies use this bug id’s in RTM to map with the test cases.