Bug Life Cycle

Like a butterfly going from egg to larva to pupa to a fully-grown butterfly,  the bug also has a life cycle. Each bug should go through the life cycle to reach a logical end. A specific life cycle ensures that the process is standardized. A life cycle is nothing but taking one thru a set of stages, as time passes by. If you take a civil lawsuit, the case goes thru a set of stages such as case filed, case hearing done, sessions court verdict given, applied to high court etc. Treat a bug as a case filed by the testing team and the project manager needs to see all cases are closed before release.

Typical stage or status codes are New, Open, Fixed (or Resolved), Retested, Closed. The codes may slightly vary from company to company, but these are the status codes that are universally accepted.

New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.

Open: After a tester has posted a bug, the lead approves that the bug is genuine and he/she changes the state as “OPEN”. This also means that the development team has acknowledged the bug. 

Fixed (Resolved): Once the developer fixes the bug, he has to change the status as Fixed and assign the bug to the testing team for retesting. Developer must also provide what kind of resolution he has done to fix the bug. 

Retested: Once the bug is fixed, the tester retests the bug in the subsequent build or in a hot-fix. If the bug is not present in the software, he sets the status to “Retested”.  

Closed: When the bug is successfully retested and the bug is not found any more, usually the test lead or manager closes the bug. This state means that the bug is fixed, retested and approve and no more exists.

Apart from the above regular stage/status codes, there are additional codes used to exactly position the bug's status. 

Reopened: If the bug still exists during retesting even after the bug is fixed by the developer, the tester changes the status to “Reopened”. The bug traverses the life cycle once again.Reopen is on the same line with Open.

 Deferred: This means the bug is expected to be fixed in next releases and not immediately. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. 
  

Rejected: If the developer feels that the bug is not genuine, he rejects the bug. 

Closed-Duplicate:If the bug is already logged by same tester or another tester in a different context, this can happen. so every tester must do a simple search in the bug tracking system whether a similar bug exists or not.

Closed-Irreproducible: Sometimes, the bug may happen due to a strange environment or data problem. The development team may not be able to exactly reproduce the bug and hence they cannot fix the same. In such a case, the bug may land up in this stage.

Closed-By-Design: When test cases were not exactly matching the specs or design, the understanding of the tester may be wrong. In such case, the bug will be closed in this manner.

Typical disputes on bugs

When someone says that you are wrong will you accept on the first shot or will you try to defend? This is typically the human behavior. More than that, if I come and tell you that your son or daughter damaged my car glass, will you defend or not?  More than defending self, one will defend more when it comes to one’s son or daughter. Same way, when a tester finds an issue on a program, many programmers will defend their program, as if it were their kids !  Quite natural. But in a professional environment this has to be handled carefully. This is usually handled in triage meetings. This section discusses the soft issues that occur due to these disputes.

This is not a bug:

 

The first resistance will be to say that it is not a bug. When this comes, we need to remove our emotions out and look at the requirements and design. As long as the product does not work as per requirements and design, it is a bug. But in some cases, the documents may be wrong or old; in that case, assign the bug to the business analyst or systems analyst to modify the requirements and/or design documents.

Over-testing of one module:

If a tester posts a bug on a module and that is overruled in triage meeting, the tester will defend the bug found. When his/her kid is ignored, when the next build comes for testing, the tester will focus more on that module irrespective of any project priorities and bring out more issues. If they are genuine, it is good. But most of the times, the issues are brought out for the sake of it with a human dislike.

If this is sensed by the Test Lead in advance, he can roll the tester to another module till time heals the attitude of the tester.

The developer pinch:

When the developer is flooded with bugs, he/she may try to talk to the tester and will show the technical superiority. It may go to the extent that the developer telling the tester “what do you know in java ? we create and you do only the testing….”. But, remember, the tester knows what customer wants. So there may be a rift between the developer and tester. If this is identified, we must ensure that the team members do not interact directly except triage meetings. Many companies put these two teams in two different buildings !

Blame it on requirements:

When more bugs are found, and development lead and test lead not getting well, both will start blaming the ambiguity and gaps in requirements. This affects project progress. The position of the business analyst will be very difficult. In this situation, the manager must stress to stick on to what is stated in specifications – nothing more, nothing less. First do, what is stated and then resolve gaps.

Push to Deliver:

When project manager overrules the results published by testing team and approves delivery to customer, the testing team will feel hurt. When the customer sends the product back pointing out the issues, again the same blame will come on the testing team only. To resolve this, we must publish delivery with known issues list to customer. This will give a better feel to testing team.