
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.
|
No comments:
Post a Comment