Five Principles of Bug Tracking

By:

A team working remotely requires much stronger discipline than a co-located crew sitting in the same office. First of all, I mean discipline of communications. At teamed.io, we have developed software remotely for the last five years. We manage tasks strictly through ticketing systems (like Github, JIRA, Trac, Basecamp, etc.) and discourage any informal communications, like Skype, HipChat, emails, or phone calls. Every ticket for us is an isolated task with its own life cycle, its own participants, and its own goal. Over these years, we've learned a few lessons that I want to share. If you also work remotely with your team, you may find them useful.

1. Keep It One-on-One
Each ticket (aka "bug") is a link between two people: problem specifier and problem solver. If it is a bug, I'm reporting it — you're solving it. If it is a question, I'm asking for an explanation — you're explaining. If it is a task, I'm ordering you to do it — you're doing it. In any case, there are two main characters. No matter how many people are involved in the ticket resolution, only these two characters have formal roles.

The responsibility of the ticket reporter is to defend the problem. When I report a bug, I have to insist that it exists — this is my job. Others may tell me that I'm wrong and the bug is not there. They may tell me that they can't reproduce it. They may say that my description of a task is too vague and nobody understands it. There may be many issues of that kind. My job is to do the best I can in order to keep the ticket alive. Obviously, if the bug is not reproducible, I'll be forced to close the ticket. However, until the ticket is closed, I'm its guardian angel. :)

On the other hand, the responsibility of the ticket solver is to defend the solution. When a ticket is assigned to me and I have to resolve it, my job is to convince the reporter that my solution is good enough. He may tell me that my solution is not sufficient, not the most efficient, or incomplete. My job is to insist that I'm right and he is wrong. Well, of course, in a reasonable way. And in order to create a solution that will be accepted as sufficient enough, I have to understand the problem first, investigate all possible options, and propose the most elegant implementation. But all this is secondary. The first thing I will be focused on is how to convince the reporter. I will always remember that my primary goal is to close the ticket.

My point here is that no matter how many people are involved in the ticket discussion, always remember what is happening there — one person is selling his solution to another person. Everybody else around them is help or distraction (see below).

2. Close It!
Remember that a ticket is not a chat. You're not there to talk. You're there to close. When the ticket is assigned to you, focus on closing it as soon as possible.

Also, keep in mind that the sooner you close the ticket, the better job you will do for the project. Long-living tickets are a management nightmare. It is difficult to track them and control them. It's difficult to understand what's going on. Have you seen those two-year-old tickets in open source projects that have hundreds of comments and no deliverables? It is a mistake by their project managers and ticket participants. Each ticket should be short and focused — 1) a problem, 2) a refinement question, 3) a short explanation, 4) a solution, 5) closed, thanks everybody. This is an ideal scenario.

As soon as you realize that your ticket is turning into a long discussion, try to close it even faster. How can I close it if the reporter doesn't like my solution? Find a temporary solution that will satisfy the reporter and allow you to close the ticket. Use "TODO" in your code or dirty workarounds — they are all better than a ticket hovering for a long time.

Once you see that the solution is provided and is sufficient enough to close the ticket, ask its reporter to close it. Explicitly ask for that; don't dance arround with "looks like this solution may be accepted, if you don't mind". Be explicit in your intention to close the ticket and move on. Try this: "@jeff, please close the ticket if you don't have any further questions."

3. Don't Close It!
Every time you raise a bug and create a new ticket, you consume project resources. Every bug report means money spent on the project: 1) money for your time spent finding the problem and reporting it; 2) for the time of the project manager who is working with the ticket and finding who will fix it; 3) for the time of the ticket solver, who is trying to understand your report and provide a solution; and also 4) for the time of everybody else who will participate in the discussion.

If you close the ticket without a problem being properly solved, you put this money into the trash bin. Once the ticket is started, there is no way back. We can't just say, "Nah, ignore it; it's not important anymore." Your ticket already consumed project time and budget resources, and in order to turn them into something useful, you have to make sure that some solution is delivered.

It can be a temporary solution. It can be a single line change in the project documentation. It can be a TODO marker in the code saying that "we are aware of the problem but won't fix it because we're lazy". Anything would work, but not nothing.

Look at it from a different perspective. When you started that ticket, you had something in mind. Something was not right with the product. That's why you reported a bug. If you close the ticket without anyone even touching that place of code, someone else will have the same concern in a few days or a few years. And then the project will have to pay again for a similar ticket or discussion of the same problem. Even if you're convinced that the issue you found in the code is not really an issue, ask a ticket resolver to document it right in the source code in order to prevent such confusion from happening again in the future.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/