Bug Statuses explained
Updated: Mar 3, 2022
The “Bug Life cycle” contains multiple stages involved in the process. During this time, the bug status can change numerous times depending on the investigation/decision that the owner makes of each phase.
Understanding the importance of each status and how it affects the decision-makers is critical when you want to implement an effective BLC process; the following table will review the available statuses that are mandatory for every BLC process, no matter what the tested software is.
Below is a list of the most common statuses related to bug reports:
Status New
A New bug is identified and reported in the bug tracking system. The bug will automatically receive the status “New,” this status will remain until the owner (Manager, Tech lead, Testing manager Etc.) reviews and approve/decline this bug.
Status Assigned
The bug owner reviews the bug (The current state is “New”); depending on the quality of the bug, the owner will decide, “What is the next step?” If the bug is detailed and approved, the owner will assign this bug to the relevant developer (that needs to fix this bug).
Status Open
This status becomes relevant if a bug with the status “New” is approved by the owner and assigned to the appropriate engineer that should fix it.
Statis Fixed
This status is set by the engineer that makes the code modifications; The basic process involved before an engineer puts this status:
The engineer receives the bug that is assigned to him.
The engineer reviews the bug and asks the relevant questions.
The engineer makes the necessary code modification.
The engineer verifies his changes.
The engineer changed the bug status to “Fixed.”
An engineer can add additional testing scenarios for verification (in addition to the original bug scenario).
The bug is moved to the person who should verify it (Usually the same person who opened it).
Status Duplicate
This status is set if the newly opened bug is already opened in the bug tracking system.
Status Invalid
This status is given to a bug in different cases that the engineer can prove that the bug is not valid, for example:
A bug that opened against the software requirements and specifications.
A bug that opened on unsupported architectures.
A bug that opened based on an invalid scenario.
Status Reopened
When a developer mark bug as “Fixed,” the bug moves to QA verification, a “Reopen” status is set in any case that the bug is reproduced with the original test scenario, when a tester changes the bug to this status, the bug returns to the Dev team for further investigation and code modifications.
Note: If the bug is reproduced with a Different scenario, we sometimes prefer to open a new bug and not “Reopen” the current one.
Status WontFix
This status is set on any bug that will not be fixed (Although it may be relevant in one case or another), For Example:
Technical limitations.
There is no economic justification to fix this bug.
Status Future Version
This status is set if the bug is moved to a future version and not fixed on the current one. Some fundamental reasons justify it, For Example :
A Bug that has low priority.
There is no time to fix it.
The fix can trigger new risks that the QA cannot re-test among the current timelines.
Bugs with minor severity.
Status By Spec/Design
This status is usually set on bugs opened by a person unfamiliar with the software design/spec; in such case, this person reports a proper behavior of the application as “Bug,” although the behavior is valid and expectable.
Status Cant reproduced
This status is set by a developer that executes the scenarios described in the bug, but the outcome is the one that is expected based on the requirements.
The basic scenario:
Status Verified/ Closed
When an engineer makes the relevant code changes, the bug is moved for verification. The appropriate person will verify that changes made to resolve the bug are working in this stage.
In my teams, I have additional criteria that must be part of the verification scenario:
The original bug is removed.
The person who verifies it should add additional tests to ensure that the code modifications don’t impact other areas of the code.