We crank out bug reports and expect them to return like a boomerang so we can check to see if the bugs were fixed. In this week's column, Danny Faught shares some ideas drawn from recent experiences that could make you a better customer advocate subsequent to filing a bug report.
Before the Bug Returns
The people on your team may add comments to a bug report as part of an ongoing dialog about how to handle the bug. This gives you a nice history about decisions and additional details about the nature of the bug and the fix. After you file a bug report and send it on its way, there may be more opportunities for you provide additional useful information.
On my current project, the programmers tend to add comments to the bug reports assigned to them when they learn new information. They also may add comments and forward the bugs to the development manager, seeking feedback. These are opportunities for me to see if there's more information I can provide about the nature of the problem that I didn't think to include when I first filed the bug. Also, I may comment on how well I think any proposed fixes will work. That greatly shortens the communication path compared to having the programmer completely implement a fix before I have a chance to review it.
Our bug tracking system notifies the team when a new comment is posted, so it's easy to track these conversations. If your system makes it more difficult to see comments posted, or if the volume of activity would make it impractical to monitor the things you're interested in, you might have to wait until the boomerang comes back to you. Also, if the programmers are hostile to receiving feedback when they're working on a bug, you're better off following a more formal process.
When the bug is fixed, more or less.
The boomerang returns...In many organizations, the people who file bug reports are asked to verify the fix when the fix is completed. Or you may be testing the fix for a bug someone else submitted. My goal is to complete this step with at least as many bugs open as when I started.
Of course, you should try to reproduce the bug the way you originally reported it. Sometimes, the problem is still there, as if nothing at all was fixed. Perhaps because of a configuration management glitch, the fix isn't in the build you have. Or maybe there's something specific about my configuration that I either didn't report or the programmer didn't think was significant. When I reject a bug fix outright, I try to include additional details about my configuration and exactly how I reproduced the bug. I use different wording than I did the first time around to help reduce any misunderstanding. And I write with a tone that expresses puzzlement rather than condemnation. In almost all cases, the programmer really did make an effort to fix the bug, and we need to recognize that effort.
What if the fix did some good but doesn't address the bug to your satisfaction? You have a judgement call to make. If the changes to the software represent some sort of progress, and can stand alone if no further improvements are made, then I recommend closing the bug as fixed. I don't like keeping a bug report open for a long time, spawning many changes, and possibly changing its focus several times.
Open one or more new bug reports, describing the additional changes you would like to see. Doing this before closing the existing bug will help make sure you don't get distracted and forget to follow up, and it will give you the ID numbers for the new bugs that you can reference in the comments when you close out the old report. It's good to leave a trail between related