Bug Tracking


As a QE, I've spent my share of time writing up problem reports, change requests, or whatever euphimism you choose to call your bug database by. I've also had the opportunity to design two different bug tracking processes.

At Rational, I designed the out-of-the-box process for ClearQuest 1.0. That gave me a great deal of time to think about how to make a generic process that customers would be able to easily adapt to their own situation. It also was the process that the ClearQuest development team used for our own bug tracking, so I spent a few months "eating my own dog food", as the expression goes. It was a significant challenge to design the fields to get adequate details into every bug, without getting in the way.

At a later job, I volunteered my time to help with the conversion from one tracking system to another. Unfortunately, I was unable to recommend ClearQuest for the job because our Customer Support team was adamant that they wanted one system for call tracking and bug tracking. That experience brought home the argument from the ClearQuest team why call tracking and bug tracking are two different applications. The "next available engineer" model just doesn't work well for bug tracking of a project under development. Maybe it works ok for a project in support, but I've never been on that side so I couldn't say.


Home
Anne Powell 8/13/01