I’m looking for the formula that predicts Post Productiion defects based on preproduction defects – I think it was by severity – Anyone familiar with this?

And this one is a beaut too:

How many test cases for a typical requirement?

Thanks for stopping by.
I’m not arguing against the use of metrics, I’m arguing againt lazy thinking.
I’m making a plea for people who are responsible for testers to make sure they have an understanding of the work before they try to measure it and that they understand the value of what that measurement is.

There is no silver bullet to measure effective testing. We need to stop asking stupid questions about a non-existant magic formula and take more interest in understanding how skilled testing adds value.

A speed indicator in a car is very useful, even if we only use it a couple of times a day when driving. But we don’t need a speed indicator to tell us if we’re going to fast down a twisty back road when the wheels squeal as we go round a corner. Our instinct and intuition tells us that we’re pushing the boundaries. Doesn’t matter what the metric says our instinct tells us that something is about to go wrong unless we correct it.

Conversely when we’re cruising down the motorway/interstate it can be difficult for our instincts to gauge if we’re going to fast or not. Cruising down the interstate there may be no physical boundary to us going to fast. So we use a metric (the speed indicator) to guide us accordingly. And in this instance we might find ourselves referring to the speed indicator on a more regular basis.

So to my mind it’s not so much if we should or shouldn’t use metrics in software testing. It’s more a case of learning to use metrics when that’s the right indicator. And learning when not to use metrics; when our instincts are a much better indicator.

William Echlin
SoftwareTesting.net