Defect Statuses | Best Practices

The “Defect 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 DLC process, the next table will review the available statuses that mandatory for every DLC process no matter what is the tested software.

Status	Description
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.) will review and approve/decline this bug.
Assigned	The bug owner review 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 need to fix this bug).
Open	This status become relevant in case that a bug with status “New” is approved by the owner and assigned to the relevant developer.
Fixed	This status is set by the developer that makes the code modifications, the basic procedure that involve before a developer can put this status: 1.       Developer receive the bug that assigned to him. 2.       Developer reviews the bug and ask the relevant questions. 3.       The Developer makes the necessary code modification. 4.       Developer verifies his changes. 5.       The Developer changed the bug status to “Fixed”. 6.       A Developer can add additional testing scenarios for verification (in addition to the original bug scenario). 7.       The bug is moved to QA for verifications.
Duplicate	This status is set in any case that the new opened bug is already opened in the bug tracking system.
Invalid	This status is given to a bug in different cases that the developer can prove that the bug is not valid, there are many cases that can support this status, examples: -          Bug that opened against the software requirements and specifications. -          Bug that opened on unsupported architectures. -          Bug that opened based on invalid scenario.
Reopened	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 change 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 Different scenario we sometimes prefer to open a new bug and not “Reopen” the current one.
Wontfix	This status is set on any bug that the dev. team cannot fix, there are a few basic reasons that may lead to this status: -          Technical limitations. -          There is no economic justification to fix this bug.
Later Version	This status is set in any case that the bug is moved to a future version and not fixed on the current one. The main reasons that may lead to such decision: -          A Bug that has low priority. -          There is not time to fix. -          The fix can trigger new risks that the QA cannot re test among the current timelines. -          Bugs with minor severity.
By Spec/design	This status is usually set on bugs that opened by a tester that unfamiliar with the software design/spec, in such case the tester reports a valid behavior of the application as “Bug” although the behavior is valid and expectable. My Personal opinion: Every bug that closed with this status is a shame for the QA person that opened it, the basic thing for every tester is to be familiar with the project requirements and design.
Cant reproduced /Worksforme	This status is set by a developer that execute the scenarios that described in the bug, but the outcome is the one that expected based on the requirements. The basic scenario: 1.       Developer receive bug. 2.       Developer executes the attached scenario. 3.       Developer examine the scenario results. 4.       The results valid and based on the SRS documentation. 5.       The Developer is marked the bug as “Worksforme” or “Could not reproduce”. 6.       The developer notifies the tester that the attached scenario is working as expected, 7.       The tester can try to reproduce the bug.
Verified/ Closed	When a developer made the relevant code changes, the bug is moved to QA team for verifications, in this stage the relevant tester will verify that the code changes are working as expected and the bug is not reproduced again. In my opinion a bug can set has “Verified””, only after that few basic criteria are answered: 1.       The original bug is removed. 2.       The tester understands d the code changes and must think about the consequences. 3.       The tester is making sure that the code changes are not affect other components.