What features are vital for good bug tracking software and why are they important? What in particular is necessary for you to consider these features done right?

9 Answers 9


Simplicity. If it's too complicated or too long to enter or sort bugs, nobody will want to use it.

  • Do you have any examples of what you consider too complex?
    – Casebash
    Oct 5, 2010 at 19:53
  • The latest product I had to use: Mantis. Way too many required steps to edit and reassign or close a ticket. Disclaimer: the version in use had not been updated for a long time. Maybe things improved since.
    – Guillaume
    Oct 6, 2010 at 14:30
  • Well, I've used Mantis extensively, and our version (also quite old) took two clicks to reassign a bug, and three clicks to close (plus entering a reason). So I can't really complain.
    – sleske
    Jul 1, 2011 at 1:21
  • @Casebash - Bugzilla is way too complex.
    – mouviciel
    Sep 14, 2011 at 9:11

Integration with SCM, so that any fixes can be traced back to the code, and code changes can be traced back to an issue. This does require vigilance to check in only code related to the issue being promoted/checked in against. i.e. no "Added feature xyz, and fixed random bugs in 4 different locations and a quick refactor of feature zyx".

Another good feature is workflow management, so that the business process is followed with the code. For example, may have a workflow path that goes something like this: Bug reported -> Triaged for priority and validity -> assigned to dev -> worked on -> assign to QA -> pass testing -> mark as closed.


Enforced ownership of bugs. It shouldn't be possible to have an open issue that is not somebody's responsibility. Other than that, simple is better.

  • 1
    Tracking items can indeed be nobody's responsibility. Oct 5, 2010 at 15:17
  • How do you see that working? Could there be a time lag before it is assigned? Or would there be some way to determine who is available?
    – JeffO
    Oct 5, 2010 at 19:27
  • When a bug is created it's assigned to the default person who decides what to do with it (could be the project lead or project manager).
    – Dan Dyer
    Oct 5, 2010 at 20:47
  • This depends on your process. If e.g. bugs are triaged on arrival, and then put into a prioritised backlog, there's no need for an owner. As a matter of fact, having an owner seems to me to be somewhat in conflict with the idea of a cross-functional team, and can introduce an artificial bottle-neck.
    – sleske
    Nov 19, 2012 at 12:53
  • Good/fast reporting capabilities. Management wants to track the bug trend.

  • API for automation,automated email notification, integration with source control, etc.

  1. custom reports: ability to quickly create and save queries of tickets, by all users not just admins. everyone likes their own view of the bugs. if this is done right, there's no need for notifications, just log in to your fave view of 'tickets on my plate'
  2. tie in to version control: should be easy to find the code changes associated with a ticket.
  3. flow intelligence: the system should not allow tickets to be in states where they'll fall through the cracks - so if status changes to 'Rejected', it should enforce assigning to someone in dev
  4. customizable: every project is different, every team is different. some teams need 8 different statuses, some just need 3. but, the GUI should remain
  5. simple: keep the key elements of the ticket big and upfront and simple. version, headline, description, status, owner
  6. history: this really stands out when it's done wrong (i'm looking at you, Unfuddle); so it should be pointed out. the history of changes to the ticket need to be visible in a nice chronological log.

I find it quite important to be able to link issues (and specify a link type, e.g. Depends on). Apart from that the usual suspects of version that the bug was found in, what version we're aiming to fix it (so we can drive road maps), an estimation field is good for project/agile planning.

Nice to haves for me are voting from the public, the ability to notify users of changes to the issue and having a fairly flexible system of categorizing the issues.

In fact pretty much everything that JIRA supports out of the box :)


Any feature that does a task for the programmer. Shouldn't it really be part of the IDE? There's the list of bugs. Pick one to work on and all of the status and time stamps are taken care of. The code changes are linked. Required tests are associated. Check it as fixed, update the status and let everyone else know about it.

  • 2
    Can be part of the IDE but should also have a part that can be accessed without IDE because there might be others involved in the project who don't use the IDE. Oct 5, 2010 at 13:19
  • @Victor Hurdagaci - good point. It needs to be accessible to everyone who needs it in an appropriate form.
    – JeffO
    Oct 5, 2010 at 19:26

Hability to identify similarities on tickets that already closed.

Could be used data mining algoritms, perhaps.


Powerful Query
The bug tracking software should help to manage the projects by enforcing rigorous development process at each stage of issue resolution.

  • 1
    This answer could be more helpful if you gave more detail. Also see the FAQ at programmers.stackexchange.com/faq for advice on how to best answer questions with not too little, not to much information. Nov 12, 2012 at 1:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.