“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?