QA Time Estimation

There are a great many people who will tell you there is a "standard" ratio of QA hours to Development hours. Don't listen to them. Anyone who makes that claim probably does not know what they are talking about.

Take for example the difference between implementing a new desktop application for internal use and implementing a new web app that is available to the general public.

In the first case, you have to verify that the application works on 1 machine configuration (the weakest CPU/Memory combination with the supported OS in your company), Security testing is restricted to making sure that the user roles are configured (if you even have role based security, there might not need to be any security testing on an internal app). Depending on a myriad of factors the QA hours for a project like this could range anywhere between 30% and 120% of the dev hours.

In the second case you need to verify that the app works on somewhere between 5 and 50 different OS/Browser combinations with several different Hardware configurations thrown in for good measure plus you now need to start throwing in web security testing where you have someone who knows what they are doing validate that your site is protected at least against the most common hacker attacks. Again depending on other factors for a project like this the QA/Dev hour ratio could be anywhere from 2/3 (66%) to 2.5/1 (250%).

This is just looking at the differences between 2 different types of new applications, some other factors that will influence the QA/Dev hour ratio are...


Maturity of the product,
Quality of the requirements,
Level of domain knowledge of the Dev/Business/ QA team members,
Development model followed (waterfall, agile, etc.),
Breakdown of roles and responsibilities between the teams (different companies have different expectations between Dev and QA) ,
Physical proximity of the Dev/Business/ QA teams (people are more efficient when they work together)
Level of quality needed (Banking and health care industries have much stricter quality requirements than an entertainment application)
Team Sizes (Smaller teams are more efficient than larger ones)
Effectiveness of Change Control Procedures
Scale of the project (Defects increase exponentially with the scale of the project, more defects means more QA time and therefore a higher ratio of QA hrs to dev hrs)
Quality of the Code (The single largest factor)
Quality of Documentation
Availability of test data (only applies to some projects)
Quality of the QA team (actually a much more minor factor than you'd think)


And I am sure there are several dozen more than I'm not thinking of off the top of my head. I have seen projects the ratio of QA hours to dev hours was as little as 1/10 (10%) and as high as 5/1 (500%) .


Now what you can do is over time develop a set of standard ratios for different types of projects at your company. You do this by first accurately measuring your projects for a year or two, then going back, finding reasonable groupings of similar projects and deriving average ratios between the two sets of time then when the next project comes up you can do a relatively simple analysis of which type of project it was most like and use that average in planning. If you do this you also need to keep measuring all future projects to ensure that the averages hold and do not drift too far over time