Ahh - the fresh smell of starting a new project, like walking in a meadow after a summer rain. Or something like that. Coming on as the QA lead in a small project with little to no formal process can be daunting, with one of the first critical steps being the implementation of a bug tracker. I figured it would be helpful to both my future self and to others to get down the critical decision points of what to consider when deciding what tool to use.
Bug tracker tool considerations
1. Local vs web-based
Do you want the hands-on of installing and managing the app yourself, whether on a dedicated rack behind your firewall or in the cloud? Or do you prefer this to be a tool accessed online with as little administrative and maintenance headaches (one can hope) as possible? Standard pro's and cons apply, most notably if you need this in-house for legal reasons (local better), and maintenance issues if you don't want to have the overhead of installation and ongoing updates and tweaks to be dependent on your dev team (web-based better).
2. Open source vs paid
Free is a good price - we all like free when it comes to software. But using open source tools come with known and unknown costs like hardware overhead and development maintenance, so sometimes it's better and simpler to pay a service fee and have your tool for a known price. Service agreements and regular updates for a paid app are also a nice benefit. But how many folks will use the tool, both now and in the near future? The more folks that use the system will also typically drive up the costs.
3. Customization options
I'm a QA snob, I admit it. I have specific fields I like to have and don't like being required to use other fields that some tools think are so necessary. I appreciate the flexibility of a defect manager that allows customizing fields, dropdown values, and even the UI so that when me or my team enters a bug, we see exactly what we need to see, no more or less.
4. Built-in workflow
Instead of having every single person know, remember, and follow the proper bug process it's great to have the bug manager do this part automatically. Many tools have a basic workflow that changes the current owner of the ticket as the status changes through its lifecycle. Other tools allow even greater depth of customization to assign the ticket to specific people of your choice for various statuses.
5. Custom filters/ queries
The detailed bug information you worked so hard to get into your system is only as good as your ability to get the data back out, specifically in a format that makes sense to you. I always look for the ability to create custom filters or queries so that I can easily pull the same report at every point in a release, such as: all bugs in current release, all in-progress tickets in current release, all non-closed bugs in current release, open tickets in next release, etc.
The ability to save these filters is half the battle - if I can spend the time once customizing my filter then have the ability to share it, not only do I save my time and sanity but I get the team familiar with the same report over and over. And considering we humans love familiarity then I've just done a favor for their sanity as well.
6. Source code integration, plugins, additional tools
Bug trackers have more and more features built into them, from wikis, timetracking, and communication tools to interactivity with other tools like Basecamp and Campfire (37Signals) and integrations with source code repositories like svn and git. These may or may not be useful depending on the toolset in use on the project, but it's well worth keeping the bigger picture in mind since the efficiency gained in choosing a tool with the right integrations can be well-worth the effort.
