Bug Life Cycle/Defect Life Cycle

Imagine a Human Life Cycle where a human being has different stages of life and each stage has a name such as Baby, Child, Adolescent, Adult and Old Age, a bug would also go through different stages starting from the point it has been reported to the point it has been closed.

These stages related to bug are termed as Status of a bug in QA terminology. Let us see the complete Bug Life Cycle now. This is also known as Defect Life Cycle. Please note that this may not be the exact life cycle that is being followed in each and every organization. But this would give a decent Idea about the life cycle.

When a QA Person creates a bug, the bug would be created with a status NEW and this bug would be assigned to QA Manager/QA Lead.

Now your QA Manager would evaluate the bug.

i. If your manager thinks that the bug doesn't have sufficient information so that a developer can understand it, then he/she would change the status of the bug to Need More Info and assign the same back to you to add more details.

ii. During evaluation if your manager thinks that the bug which you reported is not really a bug, then he/she would change the status to Rejected and would assign back the bug to you.

iii. During Evaluation if your manager thinks that the bug which you reported might be a bug, but based on the design of the software, if it can't be fixed, then the status of the bug would be changed to As Designed and the bug would be assigned back to you.

iv. During evaluation, if your manager understands or believes that there is a bug based on the snapshot(s) you have provided, but is not able to replicate/reproduce the same issue, then the same bug would be assigned back to you with the status Can't Reproduce. In such cases, you might have to investigate further to see in which cases does the bug happen. If you are also not able to replicate the bug always, you can assign the same to your manager back letting him/her know that this is an intermittent issue.

v. During Evaluation, if your manager thinks that the bug created has already been created by some one else in your team, then the status of the Bug would be changed to Duplicate and the same would be assigned back to you.

vi. Once your manager completes the evaluation and thinks that the one created by you is a bug, then he/she would assign the same to a developer without changing the status.

Now respective developer would look at the bug assigned to him/her and change the status of the bug to Open status indicating that he/she started looking into the bug.

If the developer thinks that it is not a bug or is is as designed or if he/she is unable to replicate the issue, then developer would change the status to Can't Reproduce/As Designed/Rejected.

As soon as developer agrees that it is a bug and starts working on it, the status of bug would be changed to InProgress indicating that respective developer has started working on the bug.

Once the bug has been fixed by the developer, he/she would change the status to Awaiting Build. This means that the developer has fixed the issue and the fix would be available to QA in the next coming build.

After a new build is delivered to QA, Development Lead would change all the Awaiting Build status bugs to Fixed or Resolved and assign those bugs to respective QA.

Now QA would start verifying these bugs. If QA thinks that the bug has been fixed, then the status of the bug would be changed to Closed. If QA thinks that the bug is still present, then the status of the bug would be changed to Reopened and the same would be assigned back to developer and the cycle again continues.

The bugs that are assigned to you with As Designed/Rejected/Duplicate statuses, if you agree with that, then you would close the issue. If you do not agree with that, then you would discuss the same with your manager letting them know why you feel so and you would reopen the issue.

Also in some organizations, your manager might not evaluate your bug. Rather the same would be done by the developer.