A metric that matters

Posted by joey | Posted in Metrics, Process, Teams | Posted on 01-03-2011

2

Here’s a simple metric for you: keep the number of open bug reports on zero.

Simple, eh? A yes or no – a completely binary metric. How wonderful.

After several projects that turned ugly after some time, because the number of open bug reports just rocketed to the sky I saw some general trends… general from those projects, of course, but maybe you can add your observations as comments to this blogpost so we can get some better, ahem, metrics on this.

The story goes like this:

Testers test – find and file bugs. No big reaction. A few bugs are fixed, and developers continue to work on new bits and pieces.

This pattern repeats itself for some time, then – wham-bam-slam.. a howling and drooling project manager jumps into the tester’s room and explodes into everybody’s faces: HOLYCOWTHATSALOTTABUGS!?!

You can guess the rest of the story – eventually the PM runs out of air and needs to breathe. At that time the courageous, professional and calm test manager injects a few chosen words (‘really, it’s the developers who put in the bugs, we just find them..’) to make sure the PM’s rage is properly deflated (by triggering a second round if not). And before anyone can say ‘triage’ some people are called to a meeting were the endless bug list is going to be analyzed, hackled and negotiated (‘that’s not really a bug’, ‘do we really need this’, ‘arh – I’ve seen it work before’).

As a result, because we’re busy, only around 20-25 bug reports are found worthy of the expensive developer’s time and efforts and over the next weeks they are corrected, while hundreds of new ones are added to the collection. (So, what are we really busy at?)

From here it’s a nightmare to repeat  the triage meetings, and every three or four weeks even back to the choleric PM.

So – what am I getting at here ? The simple metric – when we start finding bugs: get them fixed – right away. Maybe you’d like to loosen the metric up a bit by allowing a select few bugs to remain open for some time, but you need to be in control of the growth.

If not – the project lacks the ability to react on found bugs, and you may, as tester, ask rightfully: what did you actually expect us to do..

You can do that now, or just await the explosion..

Comments (2)

We have collected an open pub report for years. The KEY benefit of this is that we can plot an curve for the average pattern of open bugs.
In that way we can say to the PM,TM,DM,xM – yes, we usually have this many open bugs at this time in the test phase – so calm down & don’t worry :) . Or we can say: The number of active bugs are way to high and increasing, – please HELP us get rid of them.
Btw – it’s /just/ an avarage of past performances, not the truth about the future… :)

“We have collected an open pub report for years.” should be BUG report. ;-)

Write a comment