問題描述
錯誤跟踪和問題跟踪系統有什麼區別？ (What's the difference between a bug tracking and an issue tracking system?)
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.
參考解法
方法 1:
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.
方法 2:
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.
方法 3:
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
方法 4:
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.
方法 5:
it's just semantics. A bug is a problem, an issue is something to do. They are otherwise much the same.
(by Aardvark、Alan Jackson、azheglov、krubo、Ape-inago、Alister Bulman)