Choosing the proper bug tracker

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.

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

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.

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.

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.

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.

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.

Here is more information :

http://onpathtesting.com/choosing-the-proper-bug-tracker/