Imagine if Stack Overflow had a guideline: instead of asking one question, you come and ask, in the same question, whatever comes into your mind, all your issues you had for the last two weeks. What would upvote and downvote mean? What would be the titles of the questions? How to accept the best answer? How to tag the question?

Bug tracking system is done to… track bugs. Tracking a bug means:

1. Creating a record saying that a bug might exist, with information about how to reproduce it,

2. Confirming that indeed, the bug exists and is a bug, not something by design,

3. Asserting that the bug is now solved,

4. Confirming that the bug was solved.

In a very simplistic model, 1 and 4 will be done by the customer, and 2 and 3 – by the developer.

Imagine the following log:

• Day 1 [Customer] When pressing on “Remove” button in “Product details” window, the application hangs. Restarting the application shows that the product wasn’t removed. The expected behavior is to remove the product.

• Day 4 [Developer] <Issue reproduced>

• Day 5 [Developer] <Issue solved in revision 5031>

• Day 12 [Customer] <Ticket closed: issue solved>

The log is simple and clear. You can easily track what was done and when, which revision solved which bug, etc. For example, if the bug tracking system is integrated with the version control, when you view a specific revision, you can check what bugs were solved in it.

It’s easy to find information. It’s easy to see its state (is it reproduced? If the ticket was closed, why?). It’s easy to filter tickets (I want to display tickets which concern only the UI of the plugins, given that I want only tickets which are open, older than one week and assigned to me by our interaction designer and are medium or high priority).

It’s easy to reassign a ticket or to originally determine which is the person who should be in charge of the bug.

Now imagine the following log:

• Day 1 [Customer] The app hangs when I press “Remove” button in “Product details” window. Also, the background color of the left panel is dark blue, while it should be purple. I also noted that the text of the “Product details” window is not translated well to German; is it expected? When the final translation would be available? BTW, have you received the new icon I sent for the “Publish product” action? I don’t see it in the “Sync data” window.

• Day 6 [Developer] I changed the color to purple.

• Day 7 [Developer] Yes, it’s normal that the translation to German is incomplete.

• Day 8 [Customer] Ok for German. What about Italian? Lucia sent you the XML file two days ago.

• Day 9 [Developer] It’s ok now.

• Day 10 [Customer] Ok for the “Remove” button? Strange, at my computer, it still hangs.

• Day 11 [Developer] No, I wanted to say it’s ok for Italian translation.

• Day 12 [Customer] I see. Thank you. But there is a problem with the color. You changed it to dark purple, but it should be light purple, like the top panel on the main window.

• Day 13 [Developer] I updated the icon.

• Day 14 [Customer] The icon? What icon?

• Day 15 [Developer] The icon you asked me to update.

• Day 16 [Customer] I never asked you to update any icon.

• Day 17 [Developer] Of course you asked. See this ticket. You wrote that the publish product icon should be updated. I’ve done it.

  ⁞

• Day 100 [Customer] So, what about the entries in the log?

• Day 101 [Developer] I have no idea what you’re talking about. It’s not even in this ticket, but in 6199. I’m closing this one as solved. <Ticket closed: issue solved>

• Day 102 [Customer] Sorry to reopen it, but the problem is not solved. I’m talking about the entries in the log: I told you last week that the text is sometimes invalid when it contains unicode characters. Do you remember? <Ticket reopened>

• Day 103 [Developer] I vaguely remember something like that, but after searching the last three pages of this ticket, I can’t find any trace. Can you write again what was the problem?

  ⁞

• Day 460 [Developer] I spent two hours searching for a trace of what you’ve said about the files sent encrypted through the network. I’m not sure I can find the precise request.

• Day 460 [Customer] You guys should really be more organized. I notified you four times about this issue for the last two weeks. Why are you forgetting everything?

  ⁞

What’s this log about? It was solved 43 times and reopened 43 times. Does it mean that the developer is so stupid that he can’t solve the same issue for 460 days? Ah, no, wait, this ticket was assigned to 11 developers meanwhile. What’s the deal? How to search for a specific issue? It’s actually assigned to Vanessa, but her five colleagues are concerned as well by seven of the eleven issues in this ticket. When the ticket should be closed? Is it when half of the issues are solved? Or maybe ten out of eleven?

Note: You may believe that such logs don’t exist. Believe me, I’ve seen ones more than one time.

Just to comment on your statement:

can’t be it as the fix-feedback-resolved-closed should avoid that case

This assumes that all bugs raised will be fixed at the same time. Imagine a scenario where a ticket is raised against v1 of the product with two issues:

1. A form reset button actually submits the form, rather than clearing
   the values
2. The font-size on the button is 110% when it should be 115%.

Both are correct for a tester to raise, as they are both faults with the implementation. But let’s say that the product owner decides that the first subtask is a blocker to release (i.e. it has to be fixed before the product can go live), but the second task is a minor issue (i.e. it can be fixed in a v1.1 release).

In that case, we’ve no choice but to split out #2 into it’s own ticket (or risk forgetting about it). If we can do this, it means they can be implemented, tested and deployed independently of each other, in which case it makes sense to have individual issues from the start.

Scope:

This answer (and the question) seems only applicable to the tracking of code defects, where the source code does not perform according to the specification or the programmers’ intentions.

On the contrary, it is common for GUI defect tickets to contain multiple specifications, because each GUI ticket is effectively a “redesign” (design defect), a “revised specification” or a “feature request” (missing functionality).

One important purpose of defect tracking is to communicate and coordinate between multiple roles (programmers, testers, customers and managers).

In projects where code quality has high significance (compared to user-friendliness for example), defect tracking may consist of multiple facets, one of which would focus on the tracking of code defects, separately from the tracking of enhancements and customer support requests.

The purpose of code defect tracking system is:

• To enable the independent and unambiguous tracking of independently reproducible defects, and
• To provide the best approximation (one-to-one correspondence) to the root-cause of each defect.

While doing so, it should maximize the following desirable qualities:

• Scale efficiently as the number of defects increase over time.
• Prevent the moving-target syndrome.

Disclaimer: this rephrase is from my personal experience. It may be insufficient or incorrect for certification exam purpose.

Independent and unambiguous tracking means that:

1. Each valid defect can be either resolved or not resolved, without ambiguity.

   • Reason 1: to simplify management,
     • Example: it enables the use of “number of unresolved tickets” as a metric.
   • Reason 2: to translate into actionable item
     • Example: if it’s not resolved, responsibility lies on the assigned programmer. If it is resolved but not closed, responsibility lies on the assigned tester (verifier).
   • Consequence: In this methodology, a partially resolved defect deserves to be broken down into several dependent defects.

2. Independently reproducible defects should be tracked independently.

   • “Independently reproducible” means they can have different states. One can appear to be fixed while the other remains broken.
   • Reason: to minimize the mismatch between defect tracking and root-cause analysis.
     • Each root-cause that can be traced to a code defect is believed to require at least one code change.
     • If two defects are independently reproducible, then multiple code changes will be needed.
     • If two defects are independently reproducible, they must both be tested (verified), because the passing of one test does not imply that the other test will pass.
   • Example 2: if two symptoms were initially believed to have the same root-cause and thus classified into the same ticket, and they were later shown to be independently reproducible, then they should be split into two tickets.

Look at it from the perspective of someone else using the system, showing up a few months later. They find a bug in the program. They Google around and see that there’s a support ticket that matches they problem they’re having. And hey, it’s closed! Awesome! It’s been fixed in the latest version! So, they update… and the bug’s still there? What’s wrong with these stupid developers?!?

Nothing, actually. Turns out there’s something wrong with the person submitting the bug report. They submitted two bugs in the same ticket. One was easy to fix, and got fixed quickly, and the other wasn’t. Even if you use something like fix-feedback-resolved-closed, it can still be less than clear what’s going on, especially to an outside observer.

It’s much better to give each bug its own ticket, and if you have multiple bugs that are related but apparently distinct, most bug tracking systems have a feature that lets you link one bug to another. (And if not, you can just put it in the report. “See also bug #12345.”)