Bug tracking best practices

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

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 2

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 3

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 4

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 5

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 6

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 7

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 8