What is the difference between bug tracking and problem tracking?

Question

I’m looking for an explanation of why and when you will use each system, and what functions distinguish the application for tracking errors and errors.

Answer 1

Problem tracking systems typically integrate with customers and customer problems. The problem may be "help me fix this" or "How can I get the fubbar in flim flam". They may even be something like "I need an evalutation key for your software."

Error tracking systems help track errors or deficiencies in a program.

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

Answer 2

The difference may be clearer from the following example.

Suppose you had a performance problem today that affected 5 clients but was caused by one software defect.

There is a problem in your system, you opened 5 tickets and began to track what each client reported, what was reported to them when the patch for the software was applied, etc. You can track these separately for each client.

On your system, the error is tracking. You made 1 entry in which a software defect began to track things like steps for playback, code changes, etc.

Client issues may be closed when they are corrected to the degree of customer satisfaction and may or may not include software patches. An error can be closed when it is fixed and tested.

Two systems directed outward and inward, tracking two different types of things, each with its own life cycle.

Answer 3

Bug tracking systems such as Trac have one ticket for each problem inherent in the program , so the ticket closes, changing the program.

Customer support rates, such as IssueTrackerProduct , are designed to have one ticket for each customer experiencing a situation , so the ticket is closed, developing the situation for that customer (possibly by changing the program).

See Wikipedia for a comparison of problem tracking systems for examples of each.

Answer 4

Error is a subclass of the problem. All errors are problems, but not all problems are errors.

Usually an error is a defect in the code base. This differs from an incomplete / not yet implemented function or something more complicated in order to bind yourself as a developer inserting a ticket to cope with detailed technical debt or concern for the user interface. All these are “questions” semantically.

A common problem, when it does not fit into other categories, is most often a representation of something communicated by the end user. On most systems, this released issue is treated as the error report itself. I would venture to say that this is a mistake.

The hard part is that sometimes several problems can be related to other problems. This may be due to the same error, multiple errors, or actually be a function request. In other words, there may be a many-to-many relationship between problems.

Why does the difference matter? Well, inside there is a natural tree. Solving one problem can indirectly complete (or contribute to completing) a million other issues. It also affects the solution to the problem. Defects themselves can be eliminated by changing the code, which fixes it, or makes it irrelevant. If this is the user's complaint, this can be resolved by sending them work, and then left to continue when the original defect is resolved.

The functions that work better when presenting and working with these nuances in a useful way are really what you need to look for in the ticket tracking system.

At some point, you talk more about processes and methodologies than about real ticketing systems, and the actual names of things should start to become inappropriate. Mainstream and enterprise solutions focus on popular systems such as ITIL, but you can leave with adhoc, provided that everyone in the team is well versed in customer needs. I personally see this as a situation with a waterfall (ITIL) versus agile (DevOps) .

Answer 5

it's just semantics. Error is a problem, a problem is to do something. They are otherwise almost the same.

Answer 6

At best, this is a fuzzy line. A problem tracking system is likely to be considered the more general of the two. That all bug tracking systems are problem tracking systems, but not necessarily the opposite.

From our friend Wikipedia

A bug tracking system is a software application designed to help quality assurance and programmers track recorded software bugs in their work. It can be considered as a type of problem tracking system.

Answer 7

Error found in code

The problem can be found anywhere, in processes, in equipment, in people.

It depends on what kind of development process you take in relation to what the definitions mean.

Answer 8

I believe that the error can be fixed in the code, while the problem is more related to usability.

For example, the login form. An error in the login form will be the wrong form after the input is completed. Although the problem is that the general login process is too slow or there is no way to send a forgotten password.

Answer 9

This is not a complete answer to your question, but I had similar questions related to contacts with customers. I think that at the highest level, the bug tracking system is usually more focused on developers. That is, developers are trying to track down problems in the code. The function does not return the correct value, a large check must be performed, etc.

A good example of a system that goes well with code is Trac .

Problem tracking systems seem to be more customer oriented. For example, if you have a client, say "When I click" OK, I get an error message. " It may be user training, it may be a function, or it may actually be a mistake.

Thus, in many of the projects that I worked on, we save them. We have a high-level problem tracking system that may or may not lead to a real error in the error tracking system. However, many many errors are tracked internally without any “problems” created in the problem tracking system.

The problem I see between the two is that it is very difficult for inexperienced users to enter tickets into something like Trac because they get confused by technical jargon. However, the high-level problem tracking system does not integrate very closely with the code, so it is useless for developers.

Anyway ... my $ 0.02.

Answer 10

Errors : shortcomings anywhere in the process (application, database, reporting, etc.), which will prevent the appearance of 100% of the desired functionality. Also known and called defects.

Problems : potentially caused by an error or errors, a problem is a report on some form of loss of functionality in a system that is tied to a user. They are also referred to as reference tickets at some organizations.

---

WIKIPEDIA LINKS
- Software bug
- Tracking problems

Answer 11

I don’t think there is a definitive answer, but I usually just think of tracking issues as just a more general term that matches more than just “errors”. Use only the term "Error Tracking" - this is a kind of pigeon hole that is associated with software defects.

The bug tracker does not have to be tied to the software, and even BugZilla does not only track bugs, but also new enhancement requests / features, voices, etc. So I think of the “problem” as the only interesting thing that someone wants to do.

Recently, there has also been an increase in work item tracking (for example, Visual Studio and IBM / Rational Jazz ), which is a lower level than "problems" - in which a problem can be seen as requiring a certain number N of smaller work items. At a higher level, you can also see something similar to Milestone in BugZilla .

Answer 12

To answer this question, this requires context, and from his views, Alan’s answer was in your context.

In the world of software testing, one of the differences we make between a problem and a mistake is: errors are all that threaten the value of the product , while problems are something that threatens the cost of testing (or the cost of the project and, in in particular, on the cost of testing). Rapid software testing teaches us that,

In my experience, tracking systems let you make any distinction between the two. How you use a specific tracking system is up to you.

Answer 13

Errors are specific to software developers. The problems are more general and may include all the progress of team members in the project, including graphic designers, system administrators, company leaders, etc.

Problem tracking tells you what to do and can classify an item as an error if necessary.

These are mostly just silly words, but I use the “error tracker” because I work with many people who are not programmers, and we need to speak a common language with a common productivity tool that makes us aware that everyone else is doing .

You can use the error tracker, but it just confuses non-developers, especially if they have to think that their tasks are a mistake.

I would say that it is also nice to distinguish between a mistake and a problem for programmers, since errors usually represent problems with existing code, and problems can be new function requests.

Answer 14

Well ... there’s no difference except that the problem is more than just a mistake. It could be a task, a new feature, or just an improvement. An error is most often regarded as an incorrect system behavior, and the problem has a broader definition. except just "it doesn't work" ...