Even the most carefully planned and developed software is bound to have issues. While your development team can do its best to prevent these issues from occurring in the first place, perfection is almost impossible. What’s more important is knowing how to deal with bugs when they inevitably appear. This requires understanding the bug life cycle.
The bug life cycle, which is also called the defect life cycle, refers to the various states of a software issue, from initial identification to resolution. Developers classify bugs into life cycle stages so they can clearly and systematically communicate about the software bugs they deal with when developing and updating a software program.
There are typically two primary participants in the defect life cycle: the developer and the tester. The tester either identifies a bug or, in the case of a user identifying a bug, reviews the bug before assigning it to the development team. A developer then triages the issue and figures out a solution.
In some cases, especially with small development teams, there may not be dedicated testers. Instead, one or more developers will perform both roles. While this may be unavoidable for some teams due to budget or other constraints, many experts in this space recommend having both roles on the team for several reasons.
First, the two roles have different perspectives. Developers focus on creating solutions while testers focus on breaking them. In addition, having developers test their own work is similar to someone editing their own writing — it’s harder to see your own mistakes.
Regardless of your team’s composition, the bugs you’ll deal with will go through the defect life cycle below.
Breakdown of the bug life cycle
1. New
This is the initial state of any bug that’s been identified, whether by a tester, a user, or a developer. The tester performs an initial review of the bug and creates a bug report to keep track of the issue.
2. Assigned
The appropriate lead person — lead tester, project manager, or similar — assigns the bug to a developer, who takes responsibility for fixing it.
3. Open
This is where the developer analyzes the bug and attempts to find a fix. Depending on the complexity of the bug, it may stay in this state for some time.
While the developer’s ultimate goal is to fix the defect, they may need to classify the bug as one of several substates, depending on their analysis:
- Rejected. In this case, the developer has determined the system is working according to specifications and the bug isn’t a genuine defect. For example, whoever reported the bug may have misinterpreted the result.
- Duplicate. The developer has identified the bug as a copy or reasonable facsimile of another bug. Both will be resolved when one is fixed.
- Deferred. Developers may defer bugs for a number of reasons, including lack of time to address the issue or a seemingly insignificant impact on functionality.
- Not reproducible. If the developer cannot reproduce the bug, they may send it back to the tester to get more accurate reproduction steps. The tester can then reassign the bug to the developer.
4. Fixed
Once the developer produces and verifies a fix, they mark the issue as resolved and send it back to the tester.
5. Pending retest
The bug idles in this state while waiting to be tested again.
6. Retest
Once the tester begins trying to reproduce the bug, it goes into this state.
7. Reopen
If the tester finds that the bug persists despite the developer’s fix, the tester reassigns it to the developer for reassessment.
8. Verified
Assuming the tester cannot reproduce the bug and finds that the developer has truly fixed the issue, the tester marks the status as verified.
9. Closed
After verifying the bug as fixed, the tester closes out the issue.
Send Comment: