Automation is not a magical answer to the testing problem. Testing tools can never replace the analytical skills required to conduct testing and manual testing. It incurs some cost and it may not provide the desired solution if you are not careful, it is necessary that you carefully plan the automation before adopting it. Decide which tool and how many tools are required, and how many resources are required including the cost of the tool and the time spent on training.

The guidelines to be followed, if you have planned for automation in testing, are discussed here.

Consider Building a Tool instead of Buying One, if Possible

It may not be possible-every time. However, if the, requirement is small and sufficient resources allow, then go for building the tool instead of buying, after weighing the pros and cons. The decision to buy or build a tool requires management commitment, including budget and resource approvals.

Test the Tool on an Application Prototype

While purchasing the tool, it is, important to verify that it works properly with the system being developed. However, it is not possible as the system being developed is often not available. Therefore, it is suggested that if possible, the development team can build a system prototype for evaluating the testing tool.

Not All the Tests Should Be Automated

Automated testing is an enhancement of manual testing, but it cannot be expected that all test on a project be automated. It is important to decide which parts need automation before going for tools. Some tests are impossible to automate, for example, verifying a printout, It has to be done manually.

Select the Tools According to Organizational Needs

Do not buy the tools just for their popularity or to compete with other organizations, Focus on the needs of the organization and know the resources (budget, schedule) before choosing the automation tool.

Use Proven Tost-script Development Techniques

Automation can be effective if proven techniques are used to produce efficient, maintainable, and reusable test scripts. The following are some hints:

1. Read the data values from either spreadsheets or tool-provided data pools, rather than being hard-coded into the test-case script because this prevents test cases from being reused. Hard coded values should be replaced with variables and whenever possible read data from external sources.
2. Use modular script development. It increases maintainability and readability of the source code.
3. Build a library of reusable functions by separating common actions into a shared script library usable by all test engineers.
4. All test scripts should be stored in a version control tool.

Automate the Regression Tests Whenever Feasible

Regression testing consumes a lot of time. If tools are used for this testing, the testing time can be reduced to a greater extent. Therefore, whenever possible, automate the regression test cases.