I wanted to share some thoughts of mine on using a bug-tracker effectively. I started using bug-trackers about a decade ago under duress, as a way of settling an argument with a company my employer was working with. At the time, it meant that there was a more reliable TODO list than before, but we were still left with the fundamental problem which was that the TODO list wasn't being effectively managed. Over the years I've changed the way I've used bug-trackers, as my needs from them have evolved. No doubt my requirements will continue to evolve, and my usage paterns will evolve with them, so this is just where I stand now.
Ok, so, the basics. In short, every bug must be:
- reproducible
- actionable
- testable
It's just absolutely gotta be reproducible. If there's not enough information in the bug to reproduce the problem, you should treat it as a non-bug, so flick it back to the reporter. I concede that some issues are hard to reproduce and you might not get it right the first time. My advice: still close the bug as invalid, but if it gets re-opened, start a dialog with your long-suffering bug-reporter to try to extract the missing information. If they don't re-open it, well, if it's not important enough for them, it's not important enough for you.
Every bug has to be actionable. A bug that doesn't have a clear path to resolution is useless. Some examples: a crasher bug is actionable -- the action is to find out why your program is crashing under the described conditions and make it cease doing so. It sounds obvious, but there are plenty of bugs opened which don't really say to do anything at all. The most common ones are the ones that just lie outside the scope of the project; it might well be true that the ZingMaster 2000 really needs another 5000 units of zing, but at the end of the day that's another product with all the normal business considerations that go with that territory. It doesn't belong in the bug-tracker.
Finally, it's got to be testable. If there's no way to test that it's fixed, it's probably not really reproducible, but worse yet: there's no way of concluding when you've actually closed the bug.
Each bug has a discrete lifetime: it is opened, analysed, fixed, tested and finally resolved. Any bug that doesn't follow this process is really just wasting your programmers' time, and programmers are expensive. Which leads me onto the next part, which is how you can extract the maximum value from your bug-tracker, inside the framework for "legitimate" bug-tracking outlined above.
Logging
You need to make sure that you and your developers make extensive use of the "comment" feature in your bug-tracker. Put in theories, conjecture, the tests you do, anything that's relevant. Keep it up to date, and not just at the conclusion of the bug, do it as you go along. This serves a few purposes: first, the process of writing stuff down has value in and of itself, sometimes just writing things down is enough to find new ways of thinking about a problem. Similarly, anyone watching the messages from the bug-tracker might read them and offer a new insight. But the most important reason to do this is that people and bugs get re-assigned all the time. Without an accurate log of work that has been done thus far, they'll need to start from scratch, and that's wasted time.
Triage
It boils down to ruthlessness. Close bugs. It'll feel a bit strange to begin with, but after a while it'll start to feel kinda good. The bug-tracker is a work-queue, and if there's something in there that's not super-important, you should ditch it. Rely on your QA processes here, there's a reason they get paid. If there's really an issue there, it's their job to find it, so don't feel like it's all up to you.
I started this year with the goal of having no more than 10 unclassified bugs at any point in time. That was motivated by inheriting a bug database with about 200 itinerant bugs. These days I'll tolerate up to about 50 unassigned bugs, but try to stay on the low end of that. Honestly, there's just other stuff you need to do. Close bugs if you're in doubt, push them to a future version if they're going to interrupt your release schedule. The stuff that needs to be in your bug-tracker for the current version is the stuff that's actually going to stop you getting stuff out the door. Nothing more and nothing less.
Scheduling
The next thing to note is that your bug-tracker is a management tool as well as a development tool. Get everyone in your team on board with the idea that every bug that gets opened needs to have a time estimate logged against it. Then (and this is a little harder), make sure that everyone logs the time they spent fixing each bug. You shouldn't use this data to point fingers; that's not really productive. You should use it to improve your estimates on subsequent projects and that's really important for heading in the direction of the fabled "on-time software delivery". Programmers are generally pretty conscientious, so if they understand that it's not just writing quality code, but writing it to a timeline that is a deliverable, they'll generally want to use the data themselves to improve their own estimates.
There's a bit of a trap in doing this though: when it's clear that time is of the essence, the corner that tends to get cut first is testing, and that's a killer. Untested bugfixes are anathema to on-time delivery of software, so make sure your team understands that the estimates they put on the bug need to include time for testing as well as time for development.
SCM Integration
So this is something I started doing fairly recently. We started needing to manage multiple versions of the codebase simoultaneously. That meant integrating bugfixes between branches, and that meant we started losing track of what issues were fixed on what branches. The solution I came up with was to ask everyone to put a specially formatted string in the commit log that noted the bug number that was resolved in that commit. The version control system will keep track of the code that gets integrated between branches, and carries the commit messages with it. That means getting a reliable list of bugs fixed in any given version is as simple as enumerating the changesets integrated into that branch, searching for the magic string that identifies the bug numbers and looking up the details in your bug-tracker. We use Jira for bug-tracking and Perforce for version control. With those tools at my disposal, I was able to construct a Python script to generate accurate changelogs for any release branch of the code in about an hour.
This has a multitude of benefits, but mostly it means that everyone is on the same page with regard to what is fixed in what version. That helps QA, it helps your beta-testers, and it gives you some confidence about what's fixed where.
Conclusion
Your bug-tracker is the primary conduit for communication between developers and the next layer of management. If you use it properly, it can be a communication tool for other functions in your company: it can give a reliable reading on the status of a list of requested features to your products guys, and it can feed your QA guys with reliable data about the delta between revisions that they test. But most importantly, keep it lean and mean, otherwise you'll never keep your project on track.