Bug Tracker - Feature set - Comparison

Question

Hi,

I have installed and played around with a few bug tracking apps, and just wanted to get some feedback and features that a typical (or not so typical) bug tracking software has.

I want to make sure I am not overlooking a feature that might come in handy.

So the biggest idea is around a bug, which is associated with:

Bugs
- product
- product version
- component (specific component of the product)
- status
- priority
- assigned to
- expected time to finish
- time spent on it so far
- created by
- historical log of bug

Forums
Wiki

I guess the above functionality is common to all, so what exactly differentiates them?

Is it simply the UI and filtering/searching that you base a decision on?

(I am comparing something like Jira with FogBugz)

Answer 1

I realize this isn't a comprehensive answer to your question, but this will address some of what you're looking for. Check out this Wikipedia article.

Answer 2

You should also look for these features when choosing issue tracking software:

1. integration with source control
2. import and export of issues
3. reporting
4. you might also consider worklogging (time spent on an issue)
5. price!
6. support
7. continuous development or a product
8. ease of management and customization

At work we use Jira and after two years this are the marks I would give for above features:

1. 9/10 (lots of different source controls, svn with add-in)
2. 8/10 (import: cvs, bugzilla, api; export: pdf, excel, word, text, html)
3. 1/10 (poor, especially when it comes to worklog)
4. 5/10 (with some add-ins Jira gets better)
5. 7/10 (not too expensive for big teams, but not cheap enough for small)
6. 9/10
7. 6/10 (not seeing much compeling new features in new versions)
8. 7/10 (lots can be done, but it's not always easy)

Answer 3

It's a little old, but here's a good comparison resource: Bug Tracking Software Discussions that was compiled from Code Project discussions.

Answer 4

My recommendation would be to get trials of any products you wish to evaluate and put them in front of your users. I'm a FogBugz user, but from what I have seen they have somewhat different philosophies driving their development. For instance, reporting is something that FogBugz doesn't provide out of the box (see http://www.fogcreek.com/FogBugz/kb/howto/RunReports.html). mainly because they felt it doesn't encourage the appropriate behaviors in management.

Other questions you should ask yourself:

• Do I need integrated wiki capabilities? FB has this built in but Atlassian provide Confluence.
• Can I create new work items via email? FB can do this.
• Is there an easy way to create screenshots and get them into the bug tracker?
• How much information do I really need to collect? Developers are good at over specifying what information needs to be captured, rather than fixing bugs. Again this feeds into management behavior, and 'management by numbers' which is potentially a problem.
• Can I have my software log bug reports into the tracking system automatically?
• Is the system for only for tracking bugs, or does it need to support helpdesk type tracking as well?

Answer 5

You may not need to be so specific. Things like product product/version/component are really all trying to express where the affected code is likely to be.

In my experience the product/component which exhibits the problem may not actually be the cause of the problem, and you may be wasting time trying to be overly specific. If you can express where the affected code is likely to be in a more concise or simpler way, I'd encourage you to do that.

Here's my list of general things a bugtracker needs to capture. How exactly it captures these things is something you can use to compare products and decide what suits you best:

For each request: (deliberately not calling them features or bugs)

• Description. Freeform text field but STRONGLY hint that you need these:
  • What they were doing at the time
  • What they expected to happen
  • What actually happened
• Attachments (images/logfiles are often critical)
• Assigned To / Created By
• Status
• Comments
• Revision History of all practical fields

Things that are often captured but I'm personally sceptical about:

• Estimated Time/Time Taken
  • Seems like a nice idea but in my experience these are always either omitted, or incorrect, and end up serving no purpose. If you can stand over your developers with a whip and enforce that they fill in these fields you might see some more use out of them, but I can't see that being good for morale.
• Forums / Wiki
  • These are great, but they're separate products! What are they doing in your bugtracker!
• Product Version.
  • This is important, but you may not need it. On a webapp, the users only ever use one version, the latest. On desktop apps, good luck getting users to be aware of your versioning. Even Microsoft can't get people to be aware they're using office 2007 instead of office 97. It's all just "Word" to them.
• Breakdown into product sub-sections.
  • It's great to be able to produce reports that say "The Business Layer dll has 37% more defects than the integration web-service", but this is really just manager porn and doesn't help anyone get anything done. If a particular sub-section of your product is having issues your developers will tell you about it far sooner and far more accurately than any bug-tracking report.
• Seperate title field.
  • Having a seperate description/title field seems useful, but it's just more work for users. Just use the first line/x characters of the description if you need a summary. If the request doesn't make sense without a proper summary just edit it and put the summary as the first line

Answer 6

Why not use something like StackOverflow itself - in the forms of Stacked

Then you have an easy way of prioritzing features I assume...? ;)

Answer 7

In addition to others' good suggestions, look for things like

• "nagging"/"whining"
• ability for customers to have some sort of visibility into status
• customers allowed to report issues

Answer 8

An often ignored feature of the software would be the UI and user experience. There are some some tracking packages that have really get backend designs and are really customizable, but suffer from a poorly designed or frustrating to use UI. If it's maddening to use, no matter if it tracks everything you want, it's still not good software.

Answer 9

Recommend to subscribe to new online bug tracker

Answer 10

if you want to consider JIRA, bear in mind that it does not support timezones, despite a nine year old ticket asking for it. http://jira.atlassian.com/browse/JRA-9

Answer 11

I would consider VisionProject if I were you. Not only does it have a great bug tracking module, but is a project management system and a lot more as well. This helps a lot when you can have all information about the product, from the beginning of the product planning throughout the whole application lifecycle.