What is the bug life cycle? | The Jotform Blog

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.

Pro Tip

Receive bug reports and IT requests on any device with Jotform.

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.