What do you look for in a bug tracker? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

开发者_如何转开发 Improve this question

I'm interested in evaluating bug trackers, but I wanted to back up and figure out what sorts of criteria were most important in bug software. So far things I've thought of include:

• integration with source control
• usability
• basic features (email notifications, rss, case states)
• customization
• advanced features (reporting, visualizations)

• stability

• cost

• IDE integration

Any ideas?

---

Ease of use

This should, in my opinion, be on the top of your list of features to evaluate against. You want inhouse developers and testers to take any and all things they notice in the software and plug it into the tool, even if they're currently working on something else. For this to happen, the tool must be so easy to use that it stays out of the way and just takes your data. The worst bugs are those you don't know about.

A tool that has 15+ fields on the screen, where 10+ are required in order to just be able to submit the issue, is not such a system. With such a system, you'll get postit notes from testers to developers about the little things.

---

When evaluating BugTracker X, which bugtracker do the developers of BugTracker X use?

---

• customizable workflows (from "open" to "in work" to "resolved" to "closed")
• fine granular access control

---

There was a recent thread on Hacker News about this exact question. Lots of good stuff in there!

---

An API. Mandatory.

You MUST be able to catch and automatically submit bugs into your bug tracker from applications running in the field.

---

(Copy/Pasted from "Lasse V. Karlsen"'s answer)

You want inhouse developers and testers to take any and all things they notice in the software and plug it into the tool, even if they're currently working on something else. For this to happen, the tool must be so easy to use that it stays out of the way and just takes your data. The worst bugs are those you don't know about.

Even good, conscientious testers, if they are focused on testing component A but happened to stumble on a bug in component B, might not actually enter that bug if there is a lot of friction in the bug tracker. Friction means, required fields. It's not that the testers are bad or lazy - it's just how the human mind works. We focus. We don't see the guy in the gorilla suit.

The Joel/FogBugz philosophy of NO required fields is the right one (Also the philosophy of my own BugTracker.NET). You almost always can gather the details later - what os, what version, what browser, etc.

Also, take a look at "Bug Shooting", if your app has a GUI. You want to make it as easy as possible for the testers to take a screenshot and get it into the bug tracker, and that's a great tool for it. Pick a tracker that works with Bug Shooting or has its own dedicated screen shot tool.

---

Distribution. My version control system is distributed, why shouldn't my bugtracker? If I fix a bug on the train, why should I be able to make the fix but not record it?

---

Probably everything mentioned by others, plus some from me.
If you have long term big project, separate testing team that will do functional tests, you should take few additional things into consideration:
- can bugs be linked to test cases (and more precisely to given run)? - can defect tracking system exchange data with test management system?
- can it produce (useful) reports?
- can bugs be grouped by release?