Sit down (oh wait you already are). Close your eyes. Take a deep breath. Imagine a perfect world. Okay, now you need to change it so that you are picturing my perfect world.
In mine, the sun is shining, the birds are chirping, I have a cold beverage in my hand and I’m waiting for the phone to ring. The testers have the latest build and I have no cares in the world until that phone rings and I can spring into action and devote my entire time and energy to fixing the bug. I can walk over to the tester’s computer and have them reproduce the bug and then I can dive into code and fix it while they wait for the fix. Oh, the sky is purple and a flock of pigs just flew by.
Yeah, not going to happen. There are many things wrong with my perfect world. Not the least being the inefficiency of doing testing and bug fixes in serial instead of parallel (yeah call me old school).
For a typical developer a day involves working on multiple projects, switching from a discussion on delegates, attending a status meeting, checking their facebook profile and connecting to their home machine to check on the download of the latest movie (this multi-tasking is an issue for a later discussion). Compound this when you have other people in the mix: testers, support techs, project managers, customers.
With so many different demands and priorities information passed from person to person is bound to get lost. Emails are deleted, paper is recycled, conversations are forgotten. You definitely need a common shared medium that allows communication and collaboration between the different parties. The common collection point allows data on bugs and fixes to be stored and pulled up when it is convenient to each individual. The stored data in a bug database becomes invaluable as time progresses.
It allows developers to fix bugs and explain the fixes back to testers. It allows testers and developers to work on their own schedules and locations (how many people want to wake up at 6am to hear about problems with their support? no one except the tech support guys). The tool can be used by customer support to log customer complaints and give feedback to customers on the status of their issues. It can be used as a planning tool for future releases( an enhancement request is very similar to a bug and bugs can be prioritized by the number of times it is reported by an end customer ).
It should be noted that bugs are not only found in the software, they are found in other artifacts of the development process: requirements, mockups, wireframes, training material, installation procedures.
While a bit more difficult, the bug database could form the basis of a knowledge base for helping customer support: customers call in with a problem, it is logged as a bug and then a solution is given as a fix. When the next customer calls in, you search for a similar problem and then read out the solution.
The only real downside that I see to a bug tracking system is misusing it for generating non-valuable metrics on a project. People enjoy printing reports on number of open bugs, number of closed bugs per developer, number of bugs raised by tester, length of time a severity 1 issue is open. These approaches are not always helpful in understanding and managing software projects (well, maybe the last one is a valid metric), but then as I’m often the one being held responsible for the bugs my viewpoint may be a bit skewed.
What are some of the important aspects of a bug tracking tool?
- Workflow – this defines who will look at the bug and what actions that person is allowed to take.
- priority/severity – defines the importance of the bug
- description – explains how to reproduce the bug, impact of bug
- solution – explains how the bug is solved
- exportability – at one time or another you will migrate to another system. Can your data be transported with you?
There are many different bug tracking solutions out there and you need to find the one that best feeds your operational and project needs. I’ve worked with open source tools, commercial products, custom in-house solutions. Heck, I’ve used google apps to track bugs for a small project that I ran with a few friends. The key is to find one that you like and stick to it.
Some interesting and popular tools:Read Full Post | Make a Comment ( 1 so far )