Updated: Dec 2, 2020
The “Bug Life cycle” contain multiple stages that involve in the process, during this time the bug status can change multiple times depends on the investigation/decision that’s made by the owner of each phase.
Understanding the importance of each status and how it’s affecting the decision-makers, is critical when you want to implement an effective BLC process, the next table will review the available statuses that mandatory for every BLC process no matter what is the tested software.
Below, a list of the most common statuses related to bug reports:
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.) will review and approve/decline this bug.
The bug owner reviews the bug (Current state is “New”), depends on the quality of the bug the owner will decide “What is the next step?” In case that the bug is detailed and approved, the owner will assignee this bug to the relevant developer (that needs to fix this bug).
This status becomes relevant in the case that a bug with the status “New” is approved by the owner and assigned to the relevant engineer that should fix it.
This status is set by the engineer that makes the code modifications, The basic process involves before an engineer put 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 open it).
This status is set in any case that the newly opened bug is already opened in the bug tracking system.
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.
When a developer mark bug as “Fixed”, the bug moved 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.
This status is set on any bug that will not be fixed (Although it may be relevant in one case or another), For Example:
There is no economic justification to fix this bug.
Status Future Version
This status is set in any case that the bug is moved to a future version and not fixed on the current one. There are some basic reasons that 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 that are opened by a person that unfamiliar with the software design/spec, in such case this person reports a valid 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 made the relevant code changes, the bug is moved for verification. In this stage, the relevant person will verify that changes made to resolve the bug are working.
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 doesn’t impact other areas of the code.