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?