Bugs are an avoidable part of SDLC that can come up at any point in the designing, development, or user acceptance testing phase. Aiming to make a 100% bug-free software is optimistic, but not possible. That’s why testers use bug management tools to widen their test coverage and ensure that, majority of bugs are found and fixed before the deployment.
A bug goes through a specific convention of states, before it’s fixed. This is called a bug life cycle. The number of states that a defect has to pass through varies for different organizations and projects. The following are basic stages in the lifecycle of a bug.
New
Upon detection, the bug is assigned a status called “new”. This means that it’s yet to be approved or studied. Proper defect documentation is then submitted to the development team to reproduce and fix this defect. This “new” defect further undergoes many status updates.
Assigned
In this stage, the “new” bug is checked for validity and if found valid, it’s assigned to the development team by a team lead or manager. Here, the “new” status is changed to assigned.
Open
At this stage, the development team starts examining the bug and further categorizes it into states such as deferred/duplicate/not a bug/dropped.
Deferred
At times, the “assigned” bug status may be updated to “deferred” by the team lead due to various reasons.
- If the bug fix is minor or not that important
- If the bug is unassociated with the current build
- If the bug seems to get fixed by the next release
- Upon the change in customer’s requirement, the status is changed and planned to be fixed by the next release
Dropped
If an open or assigned defect is logged due to certain misinterpretation despite the system working according to the specifications then the team leads or developers mark such bugs “dropped”.
Duplicate
A similar or repeated bug is changed from an “open” status to “duplicate” by the development team.
Fixed
Upon necessary changes and verification by the developer, the status of bug is changed to “fixed”. The bug is then passed onto the testing team.
Pending Retest
After fixing the bug, a part of code is sent for retesting. It holds a ‘Pending Retest’ status since the test is to be performed at the tester’s end.
Retest
At this stage, the testing team takes over, tests the application for defects, and alters the status as “re-test”.
Reopen
After retesting, the status is updated to “reopen” if the bug is found to be fully or partially existent. The bug is then driven through the same procedure lifecycle to be fixed and completed again.
Verified
If there is no bug found after retesting, the bug is said to be fixed and the status assigned at this stage is “verified”.
Closed
If the tester or the team lead finds that the defect no longer exists, then the status of the defect is changed to “closed”. This is where the bug life cycle ends.
Conclusion
Bug statuses that are not updated in the bug management tools according to their stages can be misleading for developers and testers. Therefore, they are instructed to take care of that. Bugs need to go through these stages to ensure that they are fixed and dealt with properly. This doesn’t guarantee a 100% bug-free software but it certainly improves the quality of the software.
