Bug tracking best practices [closed]

Question

In my company, these rules apply:

• Only testers are allowed to create issues.
• Developers must send e - mail a tester to have them create an issue.
• Developers send e - mail to technical lead for having him assign an issue to themselves for issues they think they can resolve.
• A developer cannot assign an issue to another developer (Must send e - mail to technical lead).
• If a developer's issue is blocked by another developer's code, she must solve this problem outside of the bug tracking system.
• Only testers are allowed to close issues which are opened by themselves.
• All assignments must go through technical lead so he can track issues.
• Bugs that are not directly related to user interface are not entered into the system (must be resolved externally).

What bug tracking flow are you using? Does it work well for you?

Answer 1

We use BugZilla for bug tracking and there are rules like:

• Anybody can report a bug and every little change whatsoever should go through bug-tracking system. If it is an enhancement in the product, the bug should be marked as enhancement and bug-tracking system should be followed.

• Anybody can assign a bug to anybody else which means that there is ease in routing an issue to others if a bug resides in somebody else's code. There may be circumstances when a bug needs to be fixed at more than one place i.e., there is dependency on somebody else's code to get fixed first and after that other person will fix his/her code. Under those cases, a bug gets assigned to the person who needs to do the work first and then he/she re-routes the bug to appropriate person by re-assigning it.

• If an issue appears at more than one place and the code behind is different but the issue apparently is same, the bug is cloned so that a separate track can be kept of all the changes.

• Technical leads are responsible for prioritizing the bugs based on the demand of that particular fix.

• Testers/QAEs are responsible for assigning a Severity to the bug i.e., Critical/Major/Minor etc.

• All bugs go through bug-tracking system. Bugs coming from customers are classified separately by a custom flag to indicate a customer bug. Customer bugs are mostly in the older released builds and patches are created for them, therefore, those are kept separate.

This way we ensure that we keep track of all the changes simultaneously in our Source Control System (which is TFS btw) and the Bugzilla so that any changes can be traced back to the original code-change/owner if needed in the future.

Answer 2

Answer 3

Sounds pretty complicated. We are using roughly the following process:

• Everyone in the company can open an issue ticket and assigns it to a department.
• Every department has a "dispatcher" who checks the incoming tickets for validity and prioritizes them.
• Depending on the department's practices, developers are assigned tickets for the current development cycle by the dispatcher, or they assign themselves the tickets, highest priority first.
• When a ticket is solved, it goes back to whoever opened it. This person also performs all activities neccessary afterwards, like informing customers.
• All tickets are held in a software systems that makes these tasks easy. If you get a ticket, you also get an e-mail notification.

This is a lightweight process that encourages developers to take responsibility for their issues.

Aside from this, we have several quality assurance measures in place for the process of changing anything in the software, regardless of the source and type of the change requests. This includes especially:

• All code must be reviewed before it is checked into the source code management system. This includes GUI and database reviews by specialized reviewers if neccessary
• Code must be tested thoroughly by the developer himself before checking it in.
• After the monthly build, all changes have to be tested again to prevent problems that occur due to several changes affecting the same code.
• The monthly build enters a "first customer phase" where it is only rolled out to a few customer systems. If this phase shows no previously undetected errors, the build is declared safe.

Answer 4

I've used a great number of issue tracking systems, including gnats (ugh!), Bugzilla (slightly less ugh), Trac, Jira, and now FogBugz. I like Trac most of all, but that's probably because I'm not the administrator on FogBugz and it's being sadly and horribly mis-used in its current incarnation.

Getting the the workflow right is pretty crucial, and oddly enough it starts with deciding what to put in your bug tracker and how to label the things you put in there. As soon as you have a customer, all development teams really track three kinds of issues:

1. Problems noted by real customers (live bugs).

2. Problems with new software currently in development (dev bugs).

3. Things we want to do in the future (features).

Each of these three classes of issues have their own priorities, of course. A 'live bug' that's just a spelling error on a button may be a lot less important than a 'dev bug' that's blocking a publicly announced release, or gating other development, testing, etc.

The severity of an issue describes how horrible the side affects are. In my experience, this boils down to:

1. The program is ruining something. Data, customers being billed incorrectly, wrong medicine being dispensed. This is as bad as it gets. I once worked on a system where a software command retracted a hydraulic arm right through the middle of a serviceman. This is as bad as it gets.

2. The program is crashing and we don't have a work-around, but it's not ruining anything (other than being down) in the meantime. If the downtime resulta in something getting ruined use severity #1.

3. The program is misbehaving, but we have an identified work-around that can actually be used.

4. The program is misbehaving in ways that are annoying but don't affect the results.

5. The program needs to be better in some well defined way: easier to use, implement a new feature, run faster, etc.

Another problem that arises a lot in these systems is the concept of 'roles.' As applied to issue tracking systems, roles boils down to who is allowed to do things. Who gets to create issues? Who gets to change the status, who gets to reassign them to another user, who gets to close them, etc.

In the small- to mid-size teams I've worked closely with, this general set of rules has worked well:

• Anyone can create an issue. The creator can assign the issue to any (or most) recipients as it's being created. The default recipient is the Issue Triage team. Developers can note bugs they've found working on code this way, and assign the bug to themselves, to track why they are changing code.

• The Triage team meets (specify interval here) to evaluate and assign issues. The Triage team specifically looks for duplicate reports, in which case the new issue is 'rolled up' into the existing issue chain; for unreproduced issues from the field, which are assigned to QA for reproduction; and for high-severity issues from the customers.

• The originator of a bug is the ONLY person that can close it. Bug reports initiated by QA or by a CSR cannot be closed by a developer. Yes, this means that bugs that CS and the dev team disagree on remain unresolved. Why have the issue tracker report an issue as resolved when the people aren't in agreement? If you want a digital repository of lies, you have C-SPAN.

Some teams may want to reserve moving an issue from one department to another to managers, other teams may allow any team member to move an issue on to (or BACK to) another team. This may boil down to management suspicion, or simply to who is allowed to allocate work time.

The Triage process is the key. The Triage team is essentially whoever in your organization decides who works on what, and what gets worked on next. Having the team meet on a regular schedule helps to make sure that really important stuff doesn't get missed, and that the mundane stuff doesn't get dropped due to inattention. If there isn't anything in the Triage queue, the meeting (concall, netmeeting, whatever the implementation is) can be cancelled by the meeting leader.

If you're using Scrum, the Triage team is probably the scrum masters, deciding if an issue is going to be pulled into the current sprint and properly assigning the priority if it's going into the backlog.

Answer 5

Wait, you write:

If a developer's issue is blocked by another developer's code, she must solve this problem outside of the bug tracking system.

so there are bugs that fall outside of the normal bug flow. You have then a second system for tracking those bugs, or are these all ad-hoc?

Sounds like your bug tracking system is really a user-defect tracking system.

Does it work well for you or are you looking at alternatives?

Answer 6

I think that customers also should be able to create issues, with no separation between bug reports and feature requests.

Assignment of issues should not be performed by developers themselves: deciding which issues have to be fixed for next release should be of customer and manager responsibilities.

Other practices can be found in Painless Bug Tracking by Joel Spolsky.

Answer 7

I’ve used several different types of bug tracking systems over the past 10 years including nothing, a word document, FogBugz, Bugzilla, and Remedy. FogBugz is by far the best one. At that job anyone was allowed to enter bugs, and anyone could assign a bug to anyone else. I found that this worked well especially if I found a small bug in my code. Instead of spending an hour writing e-mails and filling out forms and getting several other people involved, I could quickly log that I found and fixed a bug. This encouraged me to enter all the bugs I found and fix them quickly. If a bug required a lot of work then I would assign it to my manager so he could prioritize it with my other work.
At the job where I used Bugzilla, every time a bug was created, assigned, or changed an e-mail was sent to all the developers and managers. This had the opposite effect, it discouraged me from finding and entering bugs in the system.

Answer 8

logging bugs is about speed - just the minimum amount of information needed to investigate/replicate the bug

for web projects, this comes down to: 1) a descriptive bug title, 2) the page where the error occurred, 3) a description of the problem + a screenshot OR step-by-step instructions for replicating the problem (if a screenshot isnt provided)

screenshots are very powerful for two-reasons: 1) a picture says a thousand words, 2) it gives creditability to the bug report (ever investigate a bug you couldnt replicate and think "looks like the client is making stuff up again"?)

i have a blog article which goes into the topic further: Logging Bugs Like a Pro

Answer 9

My small shop uses a pretty simple workflow:

• Anyone can create an issue (I think it's unnecessarily restrictive not to allow this) This includes customers and users of our open source projects.
• A change control board (sounds fancy, but it's just QA lead and head of engineering, plus product manager) reviews new issues and assigns fix version and priority
• Anyone can reassign a bug, to ask the reporter a question or pass on to another person to fix or test
• Anyone can mark a bug resolved
• Only QA can close a bug - we do this to enforce verification of each bug fix.

This way, everything gets logged in the bug tracking system and we keep things efficient by not restricting updates. You can end up with a bit of "bug spam" this way, but it's better than creating bottlenecks in my experience.

We use JIRA as our bug tracker - it's possible to set up all kinds of custom workflows in JIRA to enforce your particular process, but I've never found the need to do that in smaller organizations.

Answer 10

What bug tracking flow are you using?

• Tester will post the all bugs in open condition
• Assigning to Developer
• Developer will try to fix the bug - fixed
• Bug Closed
• Reopen the bug status