5 golden rules for bug tracking

Every organization, test group and tester has its own favorite bug tracking tool. Some like tight integration of these tools with source control and configuration systems where as others like it loosely coupled. Some go for the open source ones to have more control and others like proprietary one. There are even many believers of home grown tools and some still like the old Excel sheet like management. There are endless discussions so as which tool is the best. What we all forget is that a tool is a tool and the way we handle it is all that matters.


(Now this time I have a photo from my own camera 🙂 )

In my years in testing, I have used PVCS, a homegrown tool, VersionOne and lately TFS. And I have seen teams using these tools brilliantly and I have seen teams using these tools in very risky ways. I have friends praising one particular system a lot and another friend hating the same tool. In my opinion, any of these tools is good if you follow certain principles. It’s more of the culture that makes a tool and a system successful. Over years I have concluded that these are the rules that can make or break it for you:

Let everyone file a bug

The responsibility of filing a bug shouldn’t just only be tester’s rather every team member should be encouraged to file bugs. Have programmers, business analysts, documentation and support guys, project managers, product owners, scrum masters report issues that they think will add value. Even consider giving your clients access to file a bug. Seriously it works.

Let someone with vision schedule a bug

So many times the decision to schedule a bug for a particular release is given to team members who have limited vision of the product and the release. No matter how busy is “the guy who runs the show” but that guy should be looking at each bug to make a decision. I’m not saying that this responsibility cannot be delegated, but be careful that the guy being authorized has the vision.

Let make every bug pass through two or more hands

Most of the bugs that go through a normal life cycle are reported by a tester, scheduled by project manager, fixed by a programmer, verified by the same or another tester, closed by test lead. If this is not the case for you and any of the above has the authority to close a bug, it’s not good. Even for bugs that are considered ‘Not reproducible’ or ‘As Design’ should be reviewed by at least two members and not just one.

Let someone with vision close a bug

Once a bug is closed, opening it is like uprooting graves. So lot of careful consideration should be there when closing a bug. The senior most guys from testing need to take this up usually to make sure that the bug has been fixed in its original context and in totality.

Let’s not make it as a tool for our interests

Tools are used by people and all people are political. Some testers tend to use tools to portray great progress from their side by saying: “look, there are still 154 open defects” or “37 new defects were reported in last week”. The project managers can quickly create a queue of ‘unscheduled’ defects and make a release possible by lowering the remaining no. of defects. None of this is the purpose of the tool and no one should be allowed to use bug tracking ‘tool’ as a ‘tool’ to pressurize.

Do you suggest more rules that have worked for you?


Tags: ,

5 responses to “5 golden rules for bug tracking”

  1. Raza Ul Haq Akif says :

    Yes, I would like to

    Allow provision of categorization of issues for development team. I have seen this in a company where categorization from DEV team is strongly prohibited which makes the tool only for tester. Development team should have proper statuses for categorization such that they can categorize it properly e.g. if a bug is actually not a bug. This should be handle very gently to avoid any kind of unnecessary cycle. To avoid this, lead from QA and DEV can discuss the reported bug and handle it with mutual agreement. (By the way, I forgot if this comment is proper for this post :D)


    • majd says :

      Thanks Akif and the comment is definitely related. I agree that categorization should not be left to testing though in my opinion this should be done by ‘the guy who runs the show’. Specially if the decision to pick bugs for a particular release is based upon the category.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.