Tuesday, February 09, 2010

Instant Software Testing Metrics

There aren't any instant software testing metrics, at least none that give much meaning. If you are looking for instant testing metrics, sorry, this article won't provide them. I confess this title is a “hook” to get your attention. However, if you are willing to consider that it takes time to grow and understand metrics, then keep reading.

It seems that so many people I consult and train want quick and easy measures from their software development or testing efforts. I wish I had that shiny silver bullet, but in my experience and observation it takes time to really get the metrics in place that works for you and your organization.

And, really, you sure don't want to make decisions based on faulty information.

Here's why good metrics take time:

You Need History

At any point in time, a measurement is like taking one frame from a movie. For it to make sense, you need to see what has happened prior to the frame. To know how things turn out, you need to see what happens after the frame.

In software, this history starts when you start taking measurements. It continues as you keep measuring and refining your measurements.

The longer the history, the more accurate your understanding of your metrics tend to be. The key word is “understanding”. Your measurements may not necessarily get more accurate over time unless you keep questioning and improving them.

Too many people want to substitute other organizations' history for their own. I discourage this practice because every situation is different. Just because one company has a certain level of success with a given level of people or type of test technique doesn't mean you will have that same level of success.

Just start measuring a few key things that are easily obtainable and that are meaningful. It's important to track measures over time with specific dates associated with them. For example, you can start measuring the number of defects found by project. While this measure alone doesn't make a metric, you can start to see trends concerning the rate of defect discovery.

You Need Context

Metrics give context to measurements. A measure is a single count or extent of something, such as the number of defects. A metric is a measure taken in context with other measures. So, the average number of defects per function tells us the defect density from the functional perspective.

It takes time to know the best way to get this context and understand what it really means to you. I was once on a project where the client wanted to know how many test cases passed during a test. Fine. That's a good thing to know, right?

Then, people started to observe that the measure of passed tests has different meaning depending on when it is measured and reported. For example, a very high percentage of passed tests in the first round of testing may indicate the tests are too weak. Just before deployment, you want a high percentage of passed tests to indicate the application is ready to release. So, you may want to have two metrics: “first time tests that pass” and “final test pass percentage.”

You Need Time for Refinement

After you measure things for awhile, you may learn you aren't measuring the right things, or you may be measuring the right things in the wrong way.

It's fine and even expected to make major re-adjustments in your measurements. Just make sure to indicate on charts and tables when the adjustments were made.

You Need Growth

Please don't start a big metrics program with dozens of measurements. These programs often fail under their own weight. They are so big and complex, people either ignore them or give up quickly. Instead, start small and grow over time.

Metrics is a discipline that takes time and attention to do right. It also takes time to gain people's trust about how the metrics will be used. Sometimes people are fearful that the measures will be used against them, such as in a performance review.

You Need Early Successes

Pilot projects or proofs of concept are great to show the value of ideas and approaches. They reduce the risk of failure and gives you a place to practice and perfect things before trying them in the larger arena where everything becomes much more visible. It's a lot better to build positive public image based on small successes that to overcome the negative image from a major public failure.

You Need Management Understanding and Buy-in

As you grow and publish your metrics, management needs to learn the great value in them for the management of projects. Management also needs to get used to the information you can provide. They may suggest or request additional metrics or changes to existing ones. That's a good thing because it shows their minds are into the effort. This only happens over time.


I hope this shows why it takes time to get reliable and meaningful metrics. There are no magic answers, tools or techniques for getting a good set of metrics in place. That's why so few organizations reach this level. It's hard work and takes time, but it's worth the effort to show the added value you bring to your company. When you are “the” person that understands the metrics, that makes you a key person not only for your team, but for your company...and that's a very good thing!


jmm said...

Good hook, I bee-lined here ready to comment on how there are no "instant" software metrics.

When software metrics are discussed the following Lord Kelvin quote is used quite often, "when you can measure what you are speaking about and express it in numbers, you know something about it"

When I discuss software metrics I paraphrase the above quote, "when you can measure what you are speaking about and express it in numbers, you THINK you know something about it"

Anyways I like the Goal-Question-Metric paradigm for determining metrics, maybe Lord Kelvin would have too.

Randy Rice said...

Well said. I also favor the GQM paradigm. I think it is a natural way to use measurements and metrics to guide process improvement in an organic way. It's simple and effective.

Thanks for your comment!