Average Time to Test

if it takes 1000 hours to code to one requirement - that's a heck of a requirement - probably needs to be broken up into several requirements, so it makes it really hard to estimate based on
number of requirements (unless they are all that big).


Also, estimating based on the estimated number of development hours is sometimes the only (somewhat) good method to estimate if you still don't have a good idea of the functionality being coded. I've used the 30% rule before, but made sure that EVERYONE was aware that that is an INCREDIBLY rough estimation method. As soon as I get more information on the functionality and can start estimating the total number of test cases needed for new functionality and regression, a new estimate would be provided. When you can estimate the number of test cases, then you can estimate how long it will take to create and execute those test cases. And don't forget if you have to execute test cases more than once for bug fixes, etc needs to be part of the estimate too.

But, an important point to any estimation process is you can only base the estimate on the information that you have to date. As you get better information, the estimate for test SHOULD ALWAYS be updated.

No comments:

TopOfBlogs Technology Blogs - Blog Catalog Blog Directory Software blogs feeds2read