It depends on how much of the testing process you are estimating. If you are only estimating the creation and execution of test suites then the previous example is a very rough guideline. However if your testers are responsible for producing their own test plans and ensuring test environments are suitable for their own testing purposes then the estimation needs to include these factors.

The two primary elements of estimation are time and resources. Your estimation needs to take both into account.

There are many questions you need to answer in order to do test estimation. The more accurate and thorough your answers to these questions the better your test estimation.

1) What modules or functionalities will be tested and how many testers are available to test them? Of course as functionalies increase and/or number of testers decrease the more time it will take to throughly test the application.

2) What is the complexity of each of these modules or functionalities? As the complexity increases the more time and effort will be required to understand the application create test plans create test cases execute test cases regress test cases and retest defects.

3) How many test iterations (test runs) will be required to complete the test project?
This is also related to complexity. As an application becomes more complex it will typically require more test iterations to reach the company's exit critera (the number of open defects by severity and priority that a company can live with).

4) How much time will be required by developers to produce fixes for new builds between test runs? Complexity is also a factor here. As an application becomes more complex there are often more dependencies between modules and functionalities. This often requires coordination between developers. Consequently this takes more time. This is important because your estimation must also include the amount of time testers are waiting for the next build between test runs.

5) What is the average number of defects that you anticipate will be found during each test run? You may have already guessed that complexity is a factor here too. The more complex an application the greater number of defects will reach the test team when the application is released to them. In addition the more complex the application the more likely that severe and high priority defects will be found in later stages of the test process. And finally the more defects that are discovered during test runs the more time it takes to test. It takes time to author defects. It takes more time to manage defects. And it takes even more time to retest defects after they are fixed.

6) How reliable are cross-functional groups provide high quality and timely deliverables to the test team? For example if the business requirements miss important functionalities then more time will be required to recover from this oversight. Oftentimes your history with these groups will help you decide how to handle these risk factors in your estimation.

7) Don't forget that an 8-hour day is not entirely devoted to core responsibilities. Testers go to meetings read and respond to emails and do other activities that consume time throughout the day. This needs to be factored into your estimation as well.

The first thing I do in order to estimate test time and resources is to facilitate a business requirements review with all my testers. By reviewing the requirements with them it gives me a good idea about the complexity of the application. At the end of this meeting I assign functionalities to each tester. I give them several days to pour over their requirements again and get a good feel for their areas and then I ask them how much time they believe they need to 1) produce test plans 2) produce test cases and 3) map requirement to test cases. Typically I will take these numbers and apply a multiplier to account for their optimism as well as other overall risks.

There is much more to estimating than I have described in this answer but I believe it gives you a good foundation to begin with.

Jeff Kurtz