Testing as % of project time/budget

Stephan,

allocating time for quality assurance and testing will depend on your test cases and the extent of UAT. While developing the test cases one gets a fair idea about the complexity, budget and the time involved in testing. You should also have the 'User Acceptance Tests' properly documented and identified. Quality Assurance should remain an ongoing activity and depending upon your quality plan and processes followed, you should be able to predict the time and budget involved in such tasks and processes. For example, if a company is using ISO9000 QA plan they will have a fair idea of the time involved in following the processes they have defined.

Also quality and testing vary from both projects and customers. Two customers getting the same software developed might have different quality and user acceptance critrias. Preferences and priorities should be looked into.

Haris Rashid

Generally, we allocate 100% of the time spent in development for testing system/integration and user acceptance testing (UAT), split about 75/25%.

The reason why this is so long is that for every bug report you get, you have to go back and fix it, then retest.

For example, if it took 50 hours to develop a module, we expect to burn about 38 hours doing system/integration testing and about 12 hours for UAT.

The best way to answer the question is to look at results of past projects in your specific environment. Timesheet records for actual time spent on coding/QA/testing, taken in conjuntion with actual results (eg, number of bugs reported and fixed) can help find the real-world balance.

Also, remember that QA and testing are different. QA is done during design/development to AVOID errors, while testing is done afterward to FIND errors that do exist. QA time can be difficult to measure, since most of those activities are probabloy currently considered part of design and development. Definitely include time in your plan for QA above and beyond testing (eg, code reviews, signoffs, checklists & paperwork, etc).

We allocate our total testing time, typically, between 75% and 100% of development/coding time. Pre-coding activities (requirements and design) are about the same. However, the exact ratios really depend on the nature of your software and development environment/processes. Using actual historical numbers is the best way to determine this. If you don't have detail task breakouts, consulting your staff for concensus can approximate the ratios. Regardless of how you do it, once you implmeent it, measure and adjust until it seems to work well for you.

On our project, we've defined a matrix of ratios for projects based on a number of input parameters (kind of programs, size, whether they have dba work, etc). We revise these as warranted, but they're based on actual experience. They seem to work pretty well for us. Just remember to use historical information and measure/adjust.