Test Guesstimation

“How long will it take you to test?” This can be a difficult question to answer on any test team, and a lot of thought and planning is essential in order to give an accurate answer. I have seen unsuccessful teams simply add a few weeks of “buffer”, or “stabilization” time at the end of a product cycle. As you can expect, projects planned this way rarely meet customer expectations. Accurately estimating the testing task is at least as important as the act of writing software features, and deserves equal attention.

How do you estimate how long it will take you to test a feature or an application? One rule of thumb I have seen used often is to copy the development time. For example, if a particular development task is scheduled to take two man-weeks, estimating two-man weeks writing automation and describing manual test cases may be accurate. This approach is often accurate, but in practice is merely a starting point since there are so many factors that can influence the testing task. The goals of the product team, customer expectations, technical ability of the test team, and complexity of the project all influence the testing process and every tester must consider this when estimating test time. Some examples of things to consider in test estimation are:

• Historical data - At the very least, you can estimate test design based on previous projects
• Complexity - Complexity relates directly to testability. Simple applications can be tested more quickly than complex programs
• Business goals - Is the application a prototype or demonstration application? Or, is it flight control software for a spaceship? The business goals influence the breadth and depth of the testing effort
• Conformance / Compliance - If the application must conform to a standard, these requirements must be considered when estimating the testing task

Yes - this is a short list, and there are lots of other factors. How do you estimate the time it will take to design and execute tests?

Comments

• Anonymous
  March 13, 2007
  The comment has been removed
• Anonymous
  March 14, 2007
  One thing I find project teams often forget (at least at my company) is that you need to know how long it's going to take to fix the bugs that the testers find. This sounds a little silly but let me explain.If I start testing feature X from the code freeze date (waterfall method) and I can test feature X in 1 week some people would think that we can ship the product after that 1 week. But in actual fact that doesn't mean we can ship the product after that 1 week is up. We still have to go through a fix cycle to get all the bugs worked out and more regression testing to verify fixes and already tested functionality.A question I often ask to development is how long do they think it will take to fix the bugs that the testers find.We also ship based on fixed dates so in the end my testing is going to take as long as available between the time we have a product to test and the ship date :)
• Anonymous
  March 14, 2007
  Thanks both of you for the feedback. One big thing that many product managers seem to forget is that the mythical man month applies to test too.I once dealt with a GM who wanted to hire an army of temps in order to ship "on time" by buying a copy of the mythical man month, leaving it on his desk, and refusing to discuss the subject any further until after he had read the book.Granted - I did have a very good relationship with this GM, so ymmv.