Today, I spent a few hours going through our bug list. This is a process that is important but not that enjoyable.

Every software project must have a bug tracker (This is #4 in The Joel Test). The purpose of a bug tracker is to track all identified issues of the system in a central place. In David Allen’s popular Getting Things Done (GTD) methodology, this is the step: collect.

A popular tool like Bugzilla could be used as the bug tracker.

For us at OrangeHRM, it’s the bug tracker on SourceForge. The main process in which bugs get reported is QA testing. However, bugs could also get reported by developers, customers, or any other user of the software. Therefore, it is inevitable the bugs reported on the tracker would not be well organized. I have observed the following issues in bugs reported by various sources to the bug tracking system:

1. The mentioned priority of the fix is not necessarily the correct priority in the context of the project.
2. Feature requests and product enhancements get logged as bugs.
3. Misunderstood expected behavior reported as bugs.

Therefore, it is important that we implement the second step (also similar to GTD) of processing without letting developers directly pick bugs from the tracker. Ideally processing could be done by the project manager or whoever that best understands the project situation and is the decision maker of the project. Each bug should be analyzed and the following should be determined:

1. Is it really a bug that needs to be fixed? If not the tracker should be updated with the decision. Sometimes it may be required to consult the reporter before making a final decision.
2. What’s the real priority of the bug in the context of the project.

Once the real bugs and real priorities are identified, they should be added to the project planning tool used in the project. We use XPlanner for project management as our process is derived from Extreme Programming.

I usually create a story named “Bug Fixes” in each iteration in XPlanner and add all bugs as tasks under the story with its priority prefixed. (E.g. [0] - Immediate, [1] - High, [2] - Medium, [3] - Low, [4] - Trivial). XPlanner automatically sorts the list based on the prefix used such higher priority bugs appear on the top of the list. I ask the developers to pick bugs from the top of the list; fix them; and move down in the list. I repeat this process frequently such that when new higher priority bugs are added, they appear at the top of the list.

This process assures that we don’t miss any reported issues, and that we address the issues based on the real priority and we don’t waste time on lower priority tasks.