What’s the best bug tracker in the world? It depends. There’s really no such thing as a perfect bug tracker—only one that’s perfect for your team in your situation. Too much unnecessary complexity can hurt your productivity or impede adoption. Too simple for your needs and it might hamstring your work.
We compiled the key considerations for choosing the right bug tracker for your needs and designed this list around attributes of your team and technology rather than the tools themselves. You’ll still need to evaluate feature sets, but these considerations can help narrow your initial field to a manageable number.
Non-technical Users
Every team has at least some technical people, but many teams also involve non-technical people. They could be business analysts, clients, or end users, but in our experience, your less technically-inclined team members won’t be thrilled to use complex issue trackers. As a result, adoption can be a challenge, and if people can’t—or won’t—use it, the advanced features don’t matter. If non-technical folks are key to your strategy, simpler tools often yield the best results.
Criticality
Are you building software for space shuttles, medical equipment, or airplanes? Then you’ll likely need a more advanced and configurable system. In those cases, the tradeoff in ease-of-use is a no brainer. If, however, you’re building something less complex like a CMS-backed site or e-commerce store, then chances are that extra power may be overkill. In that case, something simpler requiring less training would be a better fit.
Your Technology
What technology are you using? If you’re building web sites and applications, you may want a tool that’s more focused on helping track web-page bugs. If you’re building native applications or a mix of web and native, you may be better off with something more flexible and platform-agnostic.
Similarly, if you’re building an operating system and targeting years of legacy hardware platforms and configurations, you’ll likely want to track your end users’ environments in excruciating detail for finding those really hard-to-reproduce issues.
And if you’re building a web application limited to only the most modern browsers, tracking detailed platform information is becoming less relevant with each passing month as browsers become more and more standardized. (It’s still handy, but you won’t need near the same level of detail as you might with a more varied set of target platforms.)
Your Workflow
If you have a specialized team half-a-dozen people touch each issue on its way to being closed, a simple workflow won’t cut it. You’ll need something configurable. Or if you’re a team of one, you could get by without any formal workflow at all. (We still wouldn’t suggest it, but you could.)
If you have a smaller team, chances are that a simple workflow will work best. Too many steps can create redundancy and ambiguity. That leads to nooks and crannies in which to lose or forget about bugs. Too few steps, like a todo list, and there’s no process for retesting your bugs.
The biggest challenge is finding a workflow that fits your team, and the most frequent problem that we’ve found is overly-granular bug tracker workflows. Keep it simple, and strive to reduce redundant or ambiguous statuses.
Corporate Requirements
Different companies have different security standards. Some may only allow tools to be hosted in-house behind the corporate firewall. If this is something you can’t circumvent, the key is to make sure that you’ve set aside time for setup, configuration, and ongoing maintenance for things like backups, software updates, security patches, email deliverability, and maintaining uptime. In most cases, companies that require tools to be behind the firewall have internal teams and resources to support and manage those tools, but that isn’t always the case.
With smaller teams and no corporate restrictions, a self-hosted bug tracker could need more attention and maintenance than you can spare. That can be a huge distraction when you just want to get things done, and a hosted solution is likely to make your life much easier. Instead of handling things like security, backups, and email delivery, you can just track issues. Plus you’ll get automatic updates for any new versions to boot.
Open Source or Closed Source
Are you creating open source software? If so, you’ll likely want a bug tracker that can be public facing and allow registrations. The downside with a public bug tracker is that you’ll likely end up having to deal with spam. If you’re building closed source software and can explicitly invite individual participants, a private issue tracker will prevent the spam headaches.
Team Size
It’s difficult to overlook the factor of team size, but it’s not always obvious who your “team” will be. For instance, if you’re doing work for clients, those clients will be a part of your team on each project. With clients and stakeholders, they may only use your issue tracker for short and intense periods of testing. Or, in the case maintenance agreements, they may only report bugs once or twice a month. They’ll need user accounts even though they likely won’t use it as much as your internal team.
Many paid issue trackers will charge by the seat. So you may end up paying more for those clients or team members even if they only use the bug tracker occasionally. This can lead to extra overhead of managing user access or increased costs for user accounts that won’t use their accounts as much as other team members.
Team Structure
Do you have a dedicated QA team, or do your developers and clients do the testing? Is everyone on the team behind your company firewall, or do you have external stakeholders that will need public access to your tools? Having a bug tracker that’s behind a firewall improves security, but it can also limit access for legitimate testers as well. That may lead to fewer participants and more bugs slipping through the cracks.
Will you have a discrete set of testers, like a QA team, or an infinite set of potential testers, like a public beta or open source project? With a discrete set of testers, you can use a formal bug tracker is ideal. But if you can’t explicitly provide access for each tester, you may be better off with a help desk than a bug tracker. Remember, if your bug tracker has public-facing elements, spam will likely be a concern.
The Spectrum
Bug tracking tools run the spectrum, and thankfully, there’s no shortage of options, so there’s a good chance you’ll be able to find a tool that’s just right for your team. While it would be impossible to cover every tool, we put together this spectrum of some popular tools.
Ultra Simple
These tools are simple, but they don’t provide room for an explicit retesting workflow. (You are retesting, right?)
- GitHub Issues
- Todo List Apps (Too many to list.)
Simple
These tools have fewer configuration options and are able to keep the tool simpler and easier to learn at the cost of flexibility.
Advanced
These tools are highly configurable and can generally be self-hosted, but they’ll generally have a steeper learning curve.
Project Management
Finally, there are some other great tools out there that aren’t strictly bug trackers but are flexible enough to accommodate bug tracking.
In the search for the best bug tracker for your team, the options are many and varied. There’s no right or wrong choice, only what fits your team best. Spending some time on the big picture of quality assurance when evaluating your issue tracking options can go a long ways towards helping you find the right tool.