hedgehoglab

I recently got asked by a customer about whether we eat our own dog food in using fixx (which we do) and the conversation veered towards what I think are bug tracking best practices.

A lot of the so-called best practice is just common sense (as it always is) but it is surprising how little they are used. Therefore, I thought I would share what we feel are bug tracking best practices from the view-point of 3 different roles.

For end users

When you report a software bug, it is imperative that you detail how the bug was caused in the first place. This will help the developers in finding the root cause and fixing it.

Never provide a solution unless you are a developer in-charge of the functionality. Leave it to the developer to implement the best solution.

For Developers

Be patient! We all know how frustrating bug reports can be. Try to re-assign the issue back to the reporter and ask for clarification rather than dismissing it.

Don't be defensive. I have certainly been guilty of this. No developer likes being told their code is buggy, but try to verify whether something is a bug or not before you dismiss it.

Try to use filtering, reporting and organisation features in the bug tracker to keep your focus on a specific set of issues.

Do not close issues unless you raised them. The only person who should close an issue is the person who raised the issue and can verify if it is resolved or not.

Try to provide estimates that accurately reflect the effort required for a task.

Added by David in comments - If you are working on an open source project, try to provide a suggested solution (in the form of source code patches) along with the bug report.

For Project Managers

Resist the temptation to keep adding new "fields" and meta data. Remember that the focus of the bug tracking system is not to store boat loads of information but to enable you to get things done and fix issues.

Try to keep the workflow simple. The key is to get an issue from open to closed in the fastest time possible. Complex workflows only serve bureaucracy and encourage procrastination in the process.

Trust your developers and testers to make the right decisions. Do not enforce too much control with complicated permissions and umpteen approval/review processes to get a bug resolved.

Try to keep tasks or issues that are small and achievable. "Develop a visitor management system" is not a feature/task, it is a project (as ludicrous as it may seem, this is a real world example).

Don't go overboard with reports. Project Managers love nothing more than constantly generating reports that all say the same thing with a different presentation.

I would love to hear if any of you have any other tips or best practices that you use in your organisation.

blog comments powered by Disqus