As testing organizations within a company mature, the most noteworthy process and tool that stands out is the bug tracking tool. It’s only next to the project plan in reporting the "project health". Often times the bug tracking tool is used beyond its intended use of tracking bugs. In this post, (and few of the subsequent posts) I intend to describe few of these "out of the box" usages of the bug tracking system that I've seen being used in companies I've worked for. There was an incident few years ago in my company that resulted in using the defect tracking system for tracking ‘testing Risk’. This was a new release of one of key solutions for one of our banking clients. The developers had deferred many of the significant defects to later releases because of “time pressures”. Obviously there was resistance from the testers, but as always, developers could get their way out. Once the product went to the customer, these defects turned into “significant errors and show stoppers” and these issues escalated to the highest level.
The key lesson learned from this fiasco was the testing risks often go unnoticed without an escalation mechanism beyond the project manager. The proposed solution for this problem was to track the testing risk through the bug tracking system. Proximity of the bug tracking system to the testers and developers , the "reporting features" provided by the tool as well as its inherent feature to "track" ( from opening to closure ) resulted in the bug tracking system to be the first choice.
This is how the process is followed in our organization. Every project will have a defect component for “testing risk” created in the bug tracking system. Any bug logged against this component is treated as a testing risk.
Senior management monitors this “testing risk” component on a periodic basis. The most significant benefit we’ve achieved by following this process is to bring in an early warning system into the project.
My testing risks include “Late delivery of a feature “xxxx” leaves testing group little time to test it” , “Installer of the product do not work!” , “Performance tests on the product may be inadequate” and the list goes on…
The key lesson learned from this fiasco was the testing risks often go unnoticed without an escalation mechanism beyond the project manager. The proposed solution for this problem was to track the testing risk through the bug tracking system. Proximity of the bug tracking system to the testers and developers , the "reporting features" provided by the tool as well as its inherent feature to "track" ( from opening to closure ) resulted in the bug tracking system to be the first choice.
This is how the process is followed in our organization. Every project will have a defect component for “testing risk” created in the bug tracking system. Any bug logged against this component is treated as a testing risk.
Senior management monitors this “testing risk” component on a periodic basis. The most significant benefit we’ve achieved by following this process is to bring in an early warning system into the project.
My testing risks include “Late delivery of a feature “xxxx” leaves testing group little time to test it” , “Installer of the product do not work!” , “Performance tests on the product may be inadequate” and the list goes on…
No comments:
Post a Comment