5 steps to “better” bugs

While I’m sure we’d all rather avoid defects in our software all together, in a sufficiently complex application bugs (or regressions as we also call them) are as inevitable as death and taxes.  As an old mentor used to tell me, if you aren’t failing some of the time, you aren’t trying hard enough. The trick of course is catching them before the risk they present is fully realized, i.e. in front of the end user in a production environment.  Finding and remediating bugs falls under Project Quality Management in PMBOK (Project Management Body of Knowledge, Chapter 8).

So as long as you have them, you might as well get your moneys worth out of them.  Here’s how.  A “bug” in your software system represents a defect that needs to be remediated in some way, as effectively as you can, and without breaking anything else in the system.  So how do we achieve that ?  Well we need to find them early first with good testing in a well managed development cycle, but that's the subject of another future post.  Once we have located them we need to properly assess them.  At a minimum you want to know:

1. What the defect is and what it impacts in the system.  This begins with a thorough description of the problem observed.  We are looking for a well written observation here, more than just a “its broken” but shorter than your system specification.  A paragraph should be about right.
2. How do you reproduce it.  If the developer cant reproduce it, likely it will get closed as a “non reproducible” bug and will be a complete waste of time for everyone involved.  Be as exact as possible with clear steps and any particular data needed.
3. Screen Shot or Video.  Window 7 has the built in Snipping Tool, but there are a lot of them out there.  The idea is a visible representation of what you just described.  Full motion video is even better for complicated issues. Microsoft has Expression Encoder 4 available for free , but there are many out there.
4. Priority and Impact.   I’m a big fan of two level assessment of defects.  The first level, Priority should indicate how bad the problem on a numerical scale.  P1 meaning there is no way you can go forward without releasing it, down to P4, an inconvenience.  Impact should indicate what the financial or effort based impact of this error is (I-1 to I-4).  Will it take 5 weeks to fix or do we just need to comment out a line.  Often the original tester will not be able to assess the Impact, but this should be done by the person triaging the defects.  In a project management capacity this really represents Qualitative and Quantitative Risk Assessment.  More on this two level system concept in a future post.
5. How did we fix it.  This is a critical step.  After a resolution is developed and verified, you need to detail it right in the defect document.  While we don’t need the source code here, you should link or reference the change set that fixed it.  Also, always be on the lookout for a best practice or new design pattern that worked well in approaching this defect or one that didn’t.  This is about building up your knowledgebase.

One last parting thought on defects.  While there are hundreds of theories and best practices on Software Quality Assurance and reducing bugs (and certainly worthwhile).  I like to remind people of a famous quote from Thomas Edison on the thousands of failed attempts to create the light bulb: “I have not failed. I've just found 10,000 ways that won't work.”  As long as we keep that in mind and learn from the mistakes we make during the creation process, we can indeed extract value from them rather than just writing them off as just being a costly byproduct.