Search code examples
project-managementbug-tracking

Bug tracking best practices


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?


Solution

  • 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.