QA: Estimation Techniques

There is bunch of techniques which can be used to estimate QA work.

• Industry averages, metrics, predictive models. Usually it is 30% of development work, but this is the most tricky estimates, for example developers changed store procedure this is approximately 5-8hrs of work for developer, so QA will be 1.5-2.5hrs. For QA this could mean to do full regression of application because this store procedure is using across application.
• Tester-developer ratio. This technique usually based on organization history. For example 4 developers generate work for 1 QA engineers, so QA time will be 0.25 of full development work.
• Experience (intuition, guess) based estimate. 
• Team estimation sessions. Estimates can be more accurate estimates when dev lead and BA participate in estimation sessions, more details can be provided and took into account.
• Test case based technique. This estimates can be used only when test cases created, or you can guess how many test cases you will create.
• Bottom-up approach of estimates. Work is breaking down on tasks, each task can be estimated individually and sum of tasks will be overall project estimates.

In addition to provided techniques add additional time for bugs creation and verification, for updating test case, and 30% of estimated time add as risks. Usually when QA starts estimate functionality no one know how this functionality will behave at the result. Better way to overestimate and use less time, than underestimate and use much more time of testing under pressure and not founded bugs.