Error prevention would be a tough gig to sell, but that depends on your organization. An easier sell would be to provide an estimate on the cost of the tool, the time it takes to execute an automated cycle and the number of times you would be able to reuse the automated scripts. Then compare that to how long it would take you to manually reproduce the same effort for each cycle.
If it is for an enterprise system for which you would be expecting frequent upgrades, you would have a better case.
You could also try arguing that fewer people would be required to maintain and execute automated scripts than would be to manually create the same effort for each cycle. Those metrics should not be hard to calculate.
As a last resort, you could always hit up the HP/Compuware/(insert vendor of choice) and have them come in and provide a pitch to your management team. [img]/images/graemlins/wink.gif[/img] Worst case scenario is that you might get a free lunch.
Agreed on the above, you might well have one of the professionals come in and do your selling for you. Even if you don't go with that vendor, at least management is sold [img]/images/graemlins/smile.gif[/img]
I wouldn't suggest selling error prevention either. Automation is most effective at freeing up your QA resources to do more intelligent work. So I generally say it will take me the time of 3 full test cycles to automate 50% of the application. I say 50% because it's, generally, not feasible to automate the entire application. This is something else that's important. You need to make sure they're aware that your expectation is not that automated testing will be able to find new and exciting bugs. It's to free up testing resources so they can find new and exciting bugs. Finding bugs is an exercise which requires intelligence and programming a system to work with that intelligence simply isn't feasible or realistic....yet.
I would also suggest you do your research on test automation design and understand the reasons test automation fails. If you don't build a system that is resilient to change, then you could be spending a lot of time in maintaining the test automation, which will ultimately defeat the purpose of the automation and make it a bad value proposition.
What are you honestly trying to solve through automation?
What, in your mind, would automation improve? Understand this; in a great majority of successful automation projects; the investment up front is quite high (money and/or time and/or resources). The effort involved is often up there with many moderately-sized software engineering projects.
The risk for turning the automation tool into shelfware is not trivial. There are many experienced automation engineers out there...but good ones? They're still at a premium and they can cost $$$.
Free tools require more traditional programming skills and the ones that make the promise of easy scripting are usually VERY expensive and still require great skills to make them work well.
In my opinion, if an automation tool can (at 75% of the time) run scripts without major errors in the same amount of time as a manual tester or less...it's a victory. If I can rerun that script 3 out of 4 times in a row and it only breaks when there are significant changes, well...it's probably better than having me run the same tests over and over again. Being human, I'm going to get bored...maybe take shortcuts on the tests that "never" fail and eventually get sick.
The automation script can be set to run with builds, on a schedule or on demand.
Always an improvement...if the script framework is good and the script design is solid. That's where the rubber meets the road; so to speak.