What are the core essential features of a bug tracker software?

Question

Although there is a large set of features that a bug tracker can have I feel like it is a little overkill and was considering rolling out my own solution. With that being said I didn't want to remove any core functionality that might be used frequently with existing solutions.

The ones I can think of so far: - creating bugs - assigning bugs - closing bugs - adding description to the bug

Thanks!

Answer 1

Define bug.

Thinking about that will most likely make you realize that you're gonna spend a lot of time "rolling your own".

Answer 2

A bug tracker is nothing more than a list of things that need to be done.

It can be as simple as a text file in the software's directory to a fully fledged bug tracker with hundreds of users.

Start with what you need to work with, then expand as needed.

Answer 3

This might be a little beyond what you had in mind, but for me, integration with source control is a must-have. To be able to view the diffs between versions associated with a bug/issue is very handy.

Answer 4

Use Jira, you'll be in good hands.

Answer 5

For most systems like a bug tracking one, it's usually not the creation or editing of the data that makes the system useful. It all comes down to how easily you can navigate through the information to 'add-value' on top of just collecting the data.

Think about the people who will use the system, the programmers, managers, etc. For each group of people, what type of information will make it worth their while to come back to the system over and over again. How can you make it easier for them to get this information?

Collecting information is easy, adding value to it is the hard part.

Paul.

Answer 6

• Communication between the developer and the user.
• Ability for the user to assign certain bits of information such as severity (how much that bug relates to them).
• Ability for the developer to override that priority and, if possible, give a reason.
• Ability to assign tasks to a developer.
• Ability to sort between bug, enhancement, and feature request. The difference between an enhancement and feature request is very subtle but VERY important.
• Ability to attach files (such as screen shots)
• Ability to have custom fields (such as being able to select which OS, which service pack level, application version, etc).
• Ability to have custom user profiles which also give detailed information about their hardware. It's also nice to be able to have the users phone number (if they are on your LAN) so you can ask questions, if needed.
• Privacy. Some items, such as security exploits or information that deals with financial information, will need to be kept secret. Even OSS does this from time to time until they can get a patch ready. Everyone has their own rules.
• Ability to show the changes between revisions so you can email out a Change Log so users know what you have and have not done.
• Reminders about which items are left undone and are assigned to you / unassigned at all.

That's all I can think of...

Answer 7

Please please please don;t spend much time "rolling your own". Your time is better spent researching and learning to use real tracking systems.

Some to look at

Trac, Bugzilla and FogBugz. The last one has free hosted solution for small (one or two man shops?) companies.

SO has lots of threads about this topic.

Try not to roll your own unless it is just a word doc or a spreadsheet. Any time you spend making your own is a TOTAL waste.

EDIT

Since you won't be dissuaded, then I'll maybe add some things others have not mentioned.

You need reporting functionality - users need to be able to run queries and they should be able to select the fields they want to "view".

Workflow/lifecycle of a defect is also a good feature. (basically a state machine of the states the defect will go through. ) In fact, this is a useful exercise for you to define all your use cases and functionality. Given that you are in college and did not start out as aa CS major, I doubt you will come up with many on your own. Take some time to browse the feature lists and demos of existing products.

Ability for emails to be sent to various interested parties.

Anonymous users able to see a SPECIFIC defect that they entered

Different access levels and authorities (admin, manager, developer, tester, end-user)

Answer 8

1. create a bug
2. close a bug

this is sufficient for closure over the life-cycle of a 'bug' entity. Whether it is enough features for your purpose is another matter.

Take a look at the features of Mantis, choose the features that you need, calculate how long it would take you to write them, and then spend your time on something more useful unless you absolutely have to create your own. ;-)

Answer 9

Here are some important features:

• Assign priority to bug (e.g. critical, major, medium, minor, trivial)
• Assign bug to a specific release in which it will be fixed
• Watcher functionality (so you can be e-mailed when the status changes)
• Workflow (i.e. who is working on it, what's the status)

Answer 10

FWIW: When we rolled our own request tracking system, we built it around procmail and our existing internal web authentication system because we wanted it to be extremely unobtrusive to use: we just send e-mails to the developers (using group aliases if we want) and add a "[t]" to the subject to open a ticket. The recipients get a modified e-mail with the original request and an additional link to the web page that displays the ticket and allows them to close it with 1 mouse click. So the most common tasks are performed through the e-mail client (opening, requesting more information, replying, ...), although there is also a simple web interface for searching etc.

It took only a few hours to write and after more than 34000 request tickets in 7 years or so, I guess it's OK to claim that it has only the essential core features:

• create a ticket (by e-mail with marked subject)
• close a ticket (clicking on the link in the e-mail, then clicking on "done")
• all communication goes over e-mail, not through a web interface(!)
• people who were recipients or sender of the original e-mail (opening ticket) are notified about closed tickets ("Subject: <old subject> closed by <someone>" + link to ticket in the body, enough information for most people so they don't have to go look which ticket/bug that was etc.)
• a simple web interface provides a search function for own/open/sent/team tickets

Notable absent features that might be needed for a bigger development team / more intense software development:

• flexible status for the tickets (dupe, wontfix, reopened etc.)
• priorities
• reassigning tickets explicitly (in our dev team, the e-mail just gets resent to the unlucky guy who has to do it)
• adding comments to the ticket that don't get sent to everyone
• assigning the bug to a particular version of the software

YMMV, but it has worked very well for us so far, both for bugs and for simple requests that the sender wants to keep track of.

Answer 11

Our bug tracking system is one of the two essential links between my company and our customers ("live" product reviews where existing customers are encouraged to suggest improvements and user interface tweaks being the other).

A bug tracking system must, first and foremost, encourage trackable "dialogs" with your customers. It must answer the question "Have you fixed the problem (defined broadly) that I have been having yet?"

It must have (in no particular order):

1. A short description of the problem or feature request (the title)
2. Room for an extended description
3. The ability to attach files/images (screenshots)
4. The ability to prioritize bugs/features
5. The ability to categorize entries as bugs, features, inquiry, etc.
6. The ability to assign bugs/features to areas (UI, database, documentation, etc.)
7. he ability to assign bugs/features to products (we track bugs on five products)
8. The ability to assign bugs/features to releases ("to be fixed in version 5.1")
9. The ability to assign bugs/features to people (developers/writers)
10. The ability to assign bugs/features to customers (reporters)
11. The ability to re-assign to a different person (developer)
12. The ability to Resolve bugs/features (mark them as finished and ready for testing)
13. The ability to mark resolution status (fixed, won't fix, can't reproduce, etc.)
14. The ability to Close bugs/features (take them off list after resolution & testing)
15. The ability to Reopen bugs/features (restore to "Open" if testing fails)
16. The ability to inform customers the bug has been resolved (e.g. via email)
17. Date and Time stamp on every step (Open, Resolve, Close, Re-open)
18. The ability to report on the number of Open bugs! (how close to release are we?)
19. The ability to show bug reports versus resolutions
20. The ability to search on bugs/features by date, priority, product, person, etc.
21. The ability to list and sort bugs for easy scanning!

Those are the things that we typically use in our system (FogBugz). While this may seem like a long list, we really do use every feature that I've listed here!

Answer 12

Categorization, Prioritization, and Standardization.

And an easy way to query it so that you can reap the rewards of your hard work on the above three.

Also, make sure whatever you do is extensible! We always decide to add/edit our bug templates during the project depending on needs/fires.

There are a lot of great solutions out there, you probably don't need to roll your own.. But either way you're going to have to make the same decisions. We use a solution that allows us to roll our own templates, so at the beginning of every project we revisit this same discussion.

Answer 13

A good search engine.

It's amazing how many bug tracking products that cost thousands of dollars get this horribly wrong.

Without a really decent search your bug tracking is more like a "bug logging" - log and forget - system which is pretty much useless.