What are you looking for in the bug tracker?

Question

I am interested in evaluating error tracking, but I wanted to back up and find out which criteria were most important in the error software. So far, the things I was thinking about include:

• source control integration
• usability
• main functions (email notifications, rss, case status)
• customization
• advanced functions (reporting, visualization)

• stability

• Cost

• IDE Integration

Any ideas?

Answer 1

Ease of use

This, in my opinion, should be at the top of the list of functions for evaluation. You want developers and testers to be able to take everything that they notice in the software and connect them to the tool, even if they are currently working on something else. For this to happen, the tool must be so easy to use that it stays on the sidelines and simply takes your data. The worst mistakes are those that you don't know about.

A tool with 15+ fields on the screen where 10+ is required to simply convey this problem is not such a system. With such a system, you will receive notes from testers to developers about the little things.

Answer 2

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

Answer 3

• customizable workflows (from "open" to "in work" to "allowed" to "closed")
• fine grained access control

Answer 4

There was a recent thread on Hacker News on this exact question. There is a lot of good!

Answer 5

API Mandatory.

You MUST be able to catch and automatically send errors to your error tracker from applications running in the field.

Answer 6

(copy / paste from the answer "Lasse W. Carlsen")

You want developers and testers to be able to take everything that they notice in the software and connect them to the tool, even if they are currently working on something else. For this to happen, the tool must be so easy to use that it stays on the sidelines and simply takes your data. The worst mistakes are those that you don't know about.

(End / Paste)

Even good, honest testers, if they focus on testing component A, but accidentally stumble upon an error in component B, may not actually introduce this error if there is a lot of friction in the error tracker. Friction means required fields. This does not mean that testers are bad or lazy - this is how the human mind works. We are focusing. We do not see a guy in a gorilla costume .

The philosophy of Joel / FogBugz NO required fields is correct (also the philosophy of my own BugTracker.NET). You can almost always collect the details later - what is os, which version, which browser, etc.

Also see " Bug Shooting " if your application has a graphical interface. You want to make it as simple as possible so that the testers take a screenshot and get into the error tracker, and this is a great tool for it. Choose a tracker that works with Bug Shooting or has its own screen capture tool.

Answer 7

distribution. My version control system is distributed, why shouldn't my bugtracker? If I correct a mistake on a train, why should I be able to correct, but not write it down?

Answer 8

Perhaps everything mentioned by others, plus some of me.
If you have a long-term large project, a separate testing group that will perform functional tests, you should consider several additional things:
- Is it possible to associate errors with test cases (more precisely, with a given mileage)? - Can a system track a tracking system with a test management system?
- can he create (useful) reports?
- can errors be grouped by version?