Bug Life Cycle

Whats the life cycle of a bug or a defect ?

Even though this seems like a simple problem and may not need lot of thinking but its very important to understand it well. Most of the tester spend lots of time around bugs. They report bugs, regress bugs, verify bug fixes, bounce them and so on. From the same yard stick a developer spends lots of them on and around bugs as well, tries to reproduce them, asks and gets more info to repro them, fixes them, tests the fix, comments on the bug for testing recommendation and so on.

Amid all this, dev and tester also fights a lot over bugs 🙂 and possibly all for a good cause viz. Quality. Lot of this fight can be saved or better understood if we really understand the life cycle of a bug. That way if a bug gets marked back to tester for adding more information, that would then look like routine or normal to him rather then taking that as an offensive.

So lets understand the life cycle of a bug.

A bug is found by tester and is reported. Lets assume that testers has verified it few times and is certain that its a valid, genuine and 100 % reproducible bug.

1. New Bug Reported. State – OPEN. Status – ToFix
2. Dev fixes the bug. State – OPEN. Status – ToTest. Reason – Fixed
3. Tester verifies and all is well. State – Close as Fixed.

2.1 Dev can not reproduce. So he marks it as CNR and sends it back.
2.2 Tester adds more info so that it can be reproduced.
2.3 Dev fixes the bug.
3.1 Tester verifed and all is well.
3.2 Tester verifies and he can still see the bug. Repeat.

2.2 Dev can repro but he needs more information.
and same cycle as above

2.3 Dev marks it as NotABug since thats the design
3.3 Tester would either agree and withdraw the bug or would convince dev either by showing examples in other software or making his case. Either way it gets handled later as one of the above cases.

2.4 Dev marks it as Not This Product.
3.4 This can happen when the offending code is lying in either some 3rd party code (internal or external) or there is a limitation at the end of OS or Browser or likewise. Here both the parties agree that its a bug but they are not in a position to fix this. For these bugs, we would need to work with 3rd parties and on the basis of severity and priority, we would need to either ignore it or get it fixed by 3rd party or in worse case, change our own s/w to workaround it.

2.5 Dev marks it for Deferral for next release.
3.4 These bugs are either too minor so as to not warrant time and energy or are too risky to fix at that stage of product life cycle. They are deferred for next release.

These cover the life cycle to a great extent but there are some other things as well. For example when the ‘fix’ is in a component which is being done by someone else so in that case the Status would be ‘awaiting fix’ and so on.

The key is to understand this life cycle and acknowledge that if you have a bug which has been given back to you either for adding more information or as CNR then its very much normal. If all of us understand this, then Iam sure that we will have much less conflicts and much happier transactions.

Leave a Reply

Your email address will not be published.