41

I'm looking for both an explanation of why and when you would use each system and what features differentiate a bug vs. issue tracking application.

hippietrail
  • 15,848
  • 18
  • 99
  • 158
Aardvark
  • 8,474
  • 7
  • 46
  • 64
  • 10
    One is used by people who want to sound enterprisey. – cgp Jun 02 '09 at 19:46
  • 3
    nothing but perspective, IMO. The word bug is a bit wonky and by definition doesn't include tracking 'features' which is useful, so issues is better IMO. – kenny Jun 02 '09 at 19:46
  • 4
    "Bug" is a more concrete, visceral word than "issue." "Issue" is a wimpy word that tries to make everyone feel good about their mistakes. When in doubt, go with the more Germanic, less Latinate word. "Bug tracking" ftw. – Nosredna Jun 02 '09 at 19:51
  • 5
    My CS professor once said there's no such thing as a bug, only mistakes. However, I don't think anyone sells mistake tracking software. – Matt Brunell Jun 02 '09 at 20:35
  • Thanks for all the responses!! I'll accept the highest vote-getter. – Aardvark Jun 03 '09 at 12:38
  • 1
    Don't forget 'ticketing system'. It doesn't try to say what is being ticketed, merely that tickets can be created and tracked. Both 'bug' and 'issue' end up pigeon-holing the system unnecessarily. Whether it's a bug, an issue, a task, or something else ought to be a property of the ticket, not the program you use to track them. – altendky Feb 26 '13 at 17:52
  • 1
    @Nosredna, “[At Autonomy, the word ‘bug’ is banned. No developer is allowed to use it. The tracking system does not have that word. Bugs are referred to as ‘Issues’. This is so that the **customer cannot claim that things should be fixed during the warranty period** since they aren’t recognized as bugs.](http://irisclasson.com/2013/02/19/stupid-question-154-bug-issue-or-defect-what-is-the-correct-term/)” – Pacerier Oct 03 '15 at 13:30
  • @altendky, "Ticket" is a horribly enterprisey term. Way more so than "issue". – Pacerier Oct 03 '15 at 13:30
  • @Pacerier I'm not sure I much care if it's enterprisey or not but I specifically dislike 'issue' and 'bug' because they are implying that they are only for keeping track of problems. That's very negative and quite limiting. I tried to convince my bosses boss to let us use 'tickets' in one system more flexibly and he did not like it. But he really liked another system that had 'trackers' and used them for a wide variety of things that could benefit from the data structure of a 'ticket'/'issue'/'bug'/'tracker'. Exact same thing but a different name. – altendky Oct 03 '15 at 13:48
  • @altendky, Huh, you mean you ended up with "tracker" to mean "issue"? – Pacerier Oct 04 '15 at 23:10
  • 2
    @Pacerier 'Tracker' is the term used to refer to the object. The object can be used to track an issue, a feature request, a requirement definition, a ... whatever you want to track really. An issue is just a specific type of thing to be tracked. No need to have it define the name of the overall concept of a trackable entity. – altendky Oct 05 '15 at 13:46

14 Answers14

45

Issue tracking systems usually integrate more with customers and customer issues. An issue could be "help me install this" or "How do I get the fubar into the flim flam." They could even be something like "I need an evalutation key for your software".

Bug tracking systems help you keep track of wrong or missing things from the program.

When looking at web systems, there is usually a big difference in focus, either helping customers or tracking problems with your software.

Alan Jackson
  • 6,361
  • 2
  • 31
  • 32
  • 3
    While the distinction is true, I've seen bug tracking systems used as issue tracking systems and vice versa. Using it the "wrong" way usually leads to a suboptimal experience, however. – Joachim Sauer Oct 04 '10 at 12:10
40

The difference could be clearer from the following example.

Suppose you had a production issue today that affected 5 customers, but was caused by a single software defect.

In your issue-tracking system, you opened 5 tickets and started tracking what each customer reported, what was communicated to them, when the software patch was applied, etc. You can track that kind of stuff separately for each customer.

In your bug-tracking system, you made 1 entry for the software defect started tracking things like steps to reproduce, code changes, etc.

Customer issues can be closed whenever they're remedied to the customer's satisfaction and that may or may not involve fixing the software. The bug can be closed when it's fixed and retested.

Two systems, outward- and inward-facing, tracking two different kinds of things, each with its own life cycle.

azheglov
  • 5,475
  • 1
  • 22
  • 29
  • 3
    +1 for recognising that issues are created every time a customer/user reports a problem, and that solving an issue does not imply fixing a bug in the software. – molf Jun 02 '09 at 20:17
  • 1
    Is there a place to read up about this style of issue tracking? My current place of employment needs some work on how all of this is handled and I'd like to gather information on how to better manage tickets like this. – Ape-inago Jul 10 '13 at 16:03
  • @azheglov, I'm not quite convinced by your explanation. How would you know beforehand that those 5 *issues* share the same bug? Also, how would you know beforehand when two different bugs are really one and the same? – Pacerier Oct 01 '15 at 16:30
11

Bug tracking systems like Trac are designed to have one ticket for each problem intrinsic to the program, so a ticket is closed by modifying the program.

Customer support ticket systems like IssueTrackerProduct are designed to have one ticket for each customer experiencing a situation, so a ticket is closed by working out the situation for that customer (possibly by modifying the program).

For examples of each, see Wikipedia's Comparison of issue tracking systems

krubo
  • 5,969
  • 4
  • 37
  • 46
10

A bug is a subclass of issue. All bugs are issues, but not all issues are bugs.

Typically a bug is a defect in the codebase. This is different from an incomplete/yet-to-be implemented feature, or something more hard to pin down like a developer putting in a ticket to deal with a piece technical debt, or a concern with the UI. All of these are 'issues' semantically speaking.

A generic issue, when not falling under those other categories, is more often than not a representation of something reported by the end-user. In most systems, this reported issue is handled as a bug-report in itself. I'd venture to say this is a mistake.

The tricky part is that sometimes multiple issues may be related to other issues. It could be concerning the same bug, multiple bugs, or actually be a feature request. That is to say, there can be a many-to-many relationship between issues.

Why does the distinction matter? Well, there is a natural tree internally - Resolving one issue can indirectly complete (or contribute to completing) a million other issues. It also makes a difference in how an issue is resolved. Defects themselves may be resolved with a code change that fixes it, or makes it irrelevant. If it's a user complaint, it may be resolved by sending them a work around, and then left to be followed up on when the original defect is solved.

Features that work better at representing and working with these nuances in a useful way is really what to look for in a ticket tracking system.

At some point, you are talking about processes and methodologies more than actual ticketing systems, and the actual names of things should start to become irrelevant. Mainstream and enterprise oriented solutions tend to run on a popular systems like ITIL, but you can get away with adhoc stuff provided everyone on the team has a good understanding of customer service needs. I personally see it as a waterfall (ITIL) vs agile (DevOps) situation.

Ape-inago
  • 1,870
  • 1
  • 13
  • 27
  • Regarding your second last paragraph, what software do *you* use? – Pacerier Oct 01 '15 at 16:33
  • @Pacerier I usually have two different workflows setup in Trello - one for user facing issues that is set up like a typical IT helpdesk system, and one for internal dev tickets as a scrumban - using liberal use of it's inter-linking capabilities.. I also automate a bunch of it with some custom stuff using zapier so that I can get bug reports from forms and pull in github issues as needed, or push analytics data off to spreadsheets for processing later. I've seen good things done with Autodesk, Team Foundation Server, Freshdesk, and Jira. – Ape-inago Oct 20 '15 at 10:38
  • Trello isn't a "real" bug tracking app is it? – Pacerier Oct 20 '15 at 10:45
  • Once you have it interacting with github's issue tracker, it basically looks like a kanban board. Issue tracking w/ kanban is often done with sticky notes on a wall, so its just a digitized version of that. With it's search capabilities I can quickly find existing 'bugs' and user reported issues. Plus Trello's API is pretty flexible - I even have it doing burndown charts by recording when a card is moved to a done column into a spreadsheet. – Ape-inago Oct 20 '15 at 11:04
5

it's just semantics. A bug is a problem, an issue is something to do. They are otherwise much the same.

Alister Bulman
  • 34,482
  • 9
  • 71
  • 110
  • 2
    seconded: bug == issue == problem that needs to be fixed – hometoast Jun 02 '09 at 19:59
  • 5
    -1, issue tracking systems really serve a different purpose than bug tracking systems, see many other excellent answers. – molf Jun 02 '09 at 20:18
  • I don't think its semantics... You can be told to fix bugs 1, 2, and 5 while you have a new issue that just came in as the database went down. An issue may be a bug or two, but not the same... – RSolberg Jun 02 '09 at 20:42
  • 1
    I think it is semantics. In my experience, it doesn't confuse people to put "issues" into a bug tracking database. – Nosredna Jun 02 '09 at 20:46
4

Its' a fuzzy line at best. Issue tracking system would probably be considered the more general of the two. In that all bug tracking systems are issue tracking systems, but not necessarily the opposite.

From our Friend Wikipedia

A bug tracking system is a software application that is designed to help quality assurance and programmers keep track of reported software bugs in their work. It may be regarded as a sort of issue tracking system.

Matthew Vines
  • 27,253
  • 7
  • 76
  • 97
  • 1
    Check the comment from Our Mutual Friend: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems "This page contains both issue and bug tracking systems. The distinction is uncertain in some cases, so have a look at the other category as well when missing an entry." – Aardvark Jun 02 '09 at 19:52
  • @Aardvark, @ Matthew, stop quoting half complete documents which we're supposed to edit. Directly quote the actual citations Wikipedia used. – Pacerier Oct 03 '15 at 13:31
  • @Pacerier you realize this was answered in 2009? At this point you should correct this answer if you feel it doesn't meet your standards. – Aardvark Oct 03 '15 at 13:38
4

A bug is found in code

An issue can be found anywhere, in the processes, in hardware, in people.

It depends which development process you're adopting as to what the definitions mean.

Peter
  • 1,776
  • 13
  • 20
3

I believe that a bug is something that can be fixed in code, while an issue is more of a problem with usability.

For example, a login form. A bug in the login form would be the form redirecting incorrectly after the login completes. While an issue would be that the overall login process is too slow, or there is no option to email a forgotten password.

Soviut
  • 88,194
  • 49
  • 192
  • 260
3

This isn't really a complete answer to your question, but I've had similar questions come up with dealing with customers. I think at the highest level, a bug tracking system seems usually to be more developer focused. That is, developers are trying to track problems in the code. A function isn't returning the right value, more validation should be done, etc.

A good example of a system that integrates nicely with code is Trac.

Issue tracking systems seem to be more customer-centric. For example, being able to have a customer say "When I click on 'OK" I get an error". It may be user training, it may be a feature, or it may in fact be a bug.

So in many of the projects that I've worked on we keep these distinct. We have a high-level issue tracking system that may or may not result in an actual bug being created in the bug tracking system. However, many many bugs are tracked internally without any "issues" being created in the issue tracking system.

The problem that I see between these two is that it's really not very easy for inexperienced users to enter tickets into something like Trac because they get confused by the technical lingo. However, a high-level issue tracking system does not integrate tightly with code so it's useless to the developers.

Anyway... my $0.02.

Andrew Flanagan
  • 4,267
  • 3
  • 25
  • 37
3

Bugs: flaws anywhere within the process (application, database, reporting, etc.) that will prevent 100% of desired functionality from occurring. Also known and referred to as defects.

Issues: potentially caused by a bug or bugs, an issue is a report of some form of loss of functionality in the system that would be tied to a user. These are also referred to as help desk tickets in some organizations.

WIKIPEDIA LINKS
- Software Bug
- Issue Tracking
RSolberg
  • 26,821
  • 23
  • 116
  • 160
3

To answer this question it requires context and from the looks of it Alan's answer was to your context.

In the world of software testing, one of the distinctions we make between an issue and a bug are: bugs are anything that threatens the value of the product while issues are anything that threatens of the value of testing (or the value of the project and in particular the value of testing). Rapid Software testing teaches us that.

In my experience the tracking systems allow you to make whatever distinction you want between the two. How you use a particular tracking system is up to you.

Chris Kenst
  • 279
  • 1
  • 7
2

I don't think there is a definitive answer, but I usually just think of Issue Tracking as merely a more generic term that corresponds to more than just "bugs". To only use the term "Bug Tracking" is kind of a pigeon-hole, which is associated with defects in software.

An issue tracker doesn't have to be tied to software though, and even BugZilla doesn't track only bugs, but also new enhancement / feature requests, votes, etc. In that way, I think of an "issue" as just a single item of interest that someone wants to get "done."

Lately there has also been a rise in Work Item Tracking (in e.g. Visual Studio and IBM/Rational Jazz), which is more lower level than "issues"--wherein an issue could be seen as requiring some N number of smaller work items to complete. At a higher level, you might also see something akin to a Milestone in BugZilla.

Garen
  • 941
  • 2
  • 9
  • 20
1

Bugs are specific to software developers. Issues are more general and can include all team member's progress on a project, including the graphic designers, system administrators, company executives, etc.

An issue tracker speaks in terms of things to do and can categorize an item as a bug if needed.

It is mostly just silly words, but I use an "issue tracker" as I work with many people who are not programmers, and we need to speak a common language by having a common productivity tool that makes us aware of what each other is doing.

You can use a bug tracker but it will just confuse non developers, especially if they have to think of their tasks as being a bug.

I would say it is also nice to draw a difference between a bug and an issue for programmers, as bugs are usually problems with existing code, and issues can be new feature requests.

Kekoa
  • 27,892
  • 14
  • 72
  • 91
0

Well... there is not difference besides the fact, that an issue is more than just a bug. It can be a task, a new feature, or simply an improvement. A bug is mostly seen as incorrect system behavior, while an issue has a broader definition. beyond just "it does not work"...

ReneS
  • 3,535
  • 2
  • 26
  • 35