# Estimating Test Metrics

[article]
Summary:

The goal of this paper is to discuss ways to create simple and Easy-to-use metrics to do better estimates. Estimates are important to test leads and test managers for a number of reasons. Here are some: 1) How many test cases do I need to write? 2) Can I use any of the existing test cases? 3) How many existing test cases do I need to modify? 4) How long will it take to execute the test cases? 5) How many resources do I need to write and execute the test cases?

There are no easy answers to any of these questions and we can not and should not make up numbers out of thin air (although I have seen some do just that). Primarily, there are two ways to do estimates.

Estimating the estimates: This approach of doing estimate is merely a speculation or taking a guess. It is not to say that these are wild guesses. On the contrary, this are rather informed guesses and the information comes from previous projects. Thus, estimates are done using the previous projects as a baseline. One can argue that this makes it a valid estimate. There is some truth to this argument and besides estimates are not meant to be concrete. But if the purpose of doing estimates is to come as close as possible to an absolute, then there is a chance that this approach will fall short. If estimated numbers are far a part from the actual numbers, then we are probably not doing a good job on our estimates and as a result we will be writing too few or too many test cases than we should. In order to take the guessing out of estimates, we do need to create some kind of documents which will help us to do a better estimate where estimated numbers will reflect the actual numbers (within an acceptable difference). A difference of up to 5 to 10 percent may be considered acceptable.

Documenting the estimates: The discussion of documenting the process of doing estimates will lead us to create some simple metrics which are easy to use. I have discussed one such metric in my previous article (A discussion on process, metrics, automation & outsourcing) some time ago. I needed to have some kind of measuring unit which would tell me the depth and breadth of my test coverage in detail. With that in mind I had created a metric which looks something like this (after some minor changes).