Project Management

Please login or join to subscribe to this thread

Does anyone have benchmarks for the ratio of QA to development hours for a custom software project

linkedin twitter facebook   Agile   Applications Delivery   Estimating   Information Technology  
avatar
Leslie Youngson Ottawa, Ontario, Canada
My vendor's ratio is 1.2 which seems excessive for a MS Dynamics CRM custom solution. We are using an agile approach on a T&M basis. Time spent on QA includes development of test steps, time spent executing tests and documenting bugs before release of software to client, and triaging and estimating of client feedback. If any vendors have rules of thumb they use when planning projects any insights would be appreciated. Thanks
Sort By:
< 1 2 >
avatar
Rey Battung Philippines
Hi Leslie, I think you also need to qualify your scope for QA as Tim outlined a valuable point that QA can be broken down into different stages (e.g. system test, UAT, ORT, ) depending on your Test / QA Strategy. Your Test strategy will depend on the scope / complexity / magnitude of the project. Also, will this be the very first implementation of the application? MS Dynamics CRM is a packaged app whereby if your company is already using a template solution before (and just apply specific customization to a particular client), you might be able to re-use previous test plans which can help lessen your estimate for building your test plans from scratch. It's a best practice to build or revisit your Test Strategy (if you have one already) as it will help lay out the full scope and all the effort needed to complete testing - e.g. number of cycles planned, forecasted effort needed in terms of percentage for the succeeding test cycles, etc. Add to this, you should also be clear on the exit criteria to complete Testing as you might end up chewing up more hours than needed if this is not clear - e.g. 100% closed for complex defects, 50% closed for medium/low priority defects, etc. These assumptions should be used as inputs to help measure your risks and include in your estimate. Btw, the approach I outlined below is useful for working your estimates from the bottom - up. Percentages are usually helpful in providing ballpark estimates which are usually done in the early stages of opportunity development (but depends again on specific criteria). Also, if you're company does not harvest and consolidate actual hours from previous projects, you will need to be resourceful in terms of assessing also the proficiency of your team as more experienced/skilled resources normally take less time to complete a task. Hope this helps.
< 1 2 >

Please login or join to reply

Content ID:
ADVERTISEMENTS

"I'm glad I did it, partly because it was worth it, but mostly because I shall never have to do it again."

- Mark Twain

ADVERTISEMENT

Sponsors