"We try to look at automation almost as a development project," says David Dang, a senior practice manager for Questcon Technologies. "You want to set up a plan, and from that set up the process, and from that start developing script."

This approach also keeps everyone on the same page, even if you're dealing with a large team or new team members. "Everyone is doing the same thing, so that it's a lot easier to maintain in the long run," Dang says.

During the assessment, testers should try to determine what the customer is trying to accomplish. Is the customer particular about front-end or back-end testing? Does the customer want a function, regression, or integration system? Testers should also research the client's existing environment. Does the application do object-level or business rule validation?

"From that assessment, we develop a process of framework that will approach the testing that we want to do," Dang says. Once you've assessed your goals in automating your testing, you'll be better able to determine which of the common approaches (data-driven, modular, keyword-driven, and database-driven) will offer maximum return on investment and minimum maintenance time.

Dang defines success in automation testing in terms of the return on the tester's investment—in other words, how many times he can execute an automated script with minimum changes.

He factors in both maintenance and execution time when determining the overall savings. After all, dropping a five-day project to one day of testing doesn't help much if maintenance takes another three days. A careful and consistent approach, however, might decrease that project's maintenance requirements to as little as half a day, making for a significant improvement.

Of course, a low-maintenance method will typically require more setup time—time that will potentially lead to greater savings in the long run. At the management level, this can sometimes be an obstacle.

"Management invests a lot of money on automation tools, and they want to see their return as soon as possible," Dang says. "They will see some of that if they just say, 'All right, everyone start recording and running the script.' The problem is that it will lead to maintenance costs down the line." Fortunately, Dang adds, most of today's in-touch managers are more likely to realize the value of the long-term investment.

Another stumbling block is the misdistribution of team resources. Dang and his company have found that it's best to identify within a project group two or three people with technical or development backgrounds to become the core automation experts for the team. "They will develop the script in a way where other people can execute it and add to the automation repository suite, versus having [the entire team] just scripting."

In addition to identifying automation experts, Dang recommends having team members with "the willingness to go out there and do new things, to accept alternative ideas." When you go from manual testing to automation, he says, your mindset will have to switch gears.

A little preparation—especially in terms of knowing your resources and your destination—will make that automation tool run more smoothly when it's time to hit the road.