Test Automation Funding Estimation
I need to calculate the percentage amount of development cost of a project which should go to the test automation team. I mean, if X is the project cost then what percent of X should go to the automation team. Please advice.
Re: Test Automation Funding Estimation
Using "Percentage of development cost" is a poor way to estimate the test automation cost.
It's very similar to the question "What is the correct ration of development time to test time?"
The only real answer is "it depends". It depends on the specifics of the project, the people, the expectations, etc, etc.
Some folks use history as their guide. If in the past, your test automation costs have averaged 42% of your development costs, then you could assign 42% going forward. As long as all your future projects are exactly the same as your past projects, and as long as none of your cost factors going forward change, you might be good.
One thing you can do is to estimate your automation effort, to meet certain goals, then add that estimate to the overall project estimate. For example, you can state your automation goals, estimate the number of automated tests to achieve those goals, then the effort to create those tests. Be sure to include overhead like maintenance and framework/infrastructure improvements.
In my view, the automation effort should be estimated the same way you would estimate the development effort. It's still software development, still needs to integrate with legacy code (existing automation), and still needs to be developed, tested, and deployed. Estimation for automation projects also needs to include data generation and development.
I've never seen the set percentage of total costs work for the reasons Joe's given. What usually happens when that method is used is that the automation time allocated gets eaten because of assorted unforeseen circumstances (I've never been involved with a project that had any kind of slack time built in, either, so the first time someone was ill or ran into something they hadn't expected, the project was in trouble), then the manual test time gets cut (but somehow the release date never shifts...) and automation goes on the long list of things to be added "when there's time".
In addition, the real costs of automation scare many project management and upper management people because they don't see any benefit from the initial implementation. The benefits of automated regression always manifest in subsequent releases so they see a big up-front cost with slow, incremental returns (If you add automation to test feature A in release X, the benefit starts to show in release X+1 and continues from then forward. If you took the time and did things the slower, more expensive way up front, your maintenance costs will be lower, so the benefits will continue to grow. Unfortunately they'll be "soft" benefits - time that didn't have to be spent in manual regression, bugs that didn't go to the customers, that kind of thing. It's hard to put a dollar value on that, particularly since it's very rare to have two bugs that are alike enough to compare them).