Typical test automation comprises of following steps –

• Setting up the test pre conditions.
• Execute the tests
• Comparing results with the known oracles
• Reporting results

If planned properly, test automation could be one of the most important testing activities and can yield tremendous gains. There are many tools available in the market for test automation from all the major tool vendors. Many tools are available from the open-source community as well. Most of these tools are focused on the automated record and playback types of testing.

In the short term, record and playback type of testing can yield fast results but can become cumbersome over a period of time and require considerable amount of resources to maintain them. Generally regression testing is a good candidate for automation because of its repeatable nature.

Similar to software development, there are many frameworks that can be used even for the test automation. A test automation framework can be defined as a set of assumptions, concepts, and practices that constitute a work platform or support for automated testing. There are five different types of test automation frameworks which can be used for the development of the test automation as described by Kelly in his article at developerworks.

• Test script modularity framework – This framework is probably the simplest to follow. In this framework, small, independent scripts that represent modules, sections and functions of the application under test are created. These small scripts are than used to create larger test cases. The test script modularity framework applies principle of abstraction or encapsulation in order to improve the maintainability and scalability of automated test suites


• The test library architecture framework - The test library architecture framework is very similar to the test script modularity framework and offers the same advantages, but it divides the application-under-test into procedures and functions instead of scripts. This framework requires the creation of library files (APIs, DLLs, and such) that represent modules, sections, and functions of the application-under-test. These library files are then called directly from the test case script.


• Keyword Driven Testing Framework - Keyword-driven testing refer to an application-independent automation framework. This framework requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test script code that "drives" the application-under-test and the data.


• Data Driven Testing Framework - Data-driven testing is a framework where test input and output values are read from data files (data-pools, ODBC sources, CSV files, Excel files, DAO objects, ADO objects, and such) and are loaded into variables in captured or manually coded scripts. In this framework, variables are used for both input values and output verification values. Navigation through the program, reading of the data files, and logging of test status and information are all coded in the test script. This is similar to table-driven testing in that the test case is contained in the data file and not in the script; the script is just a "driver," or delivery mechanism, for the data. Unlike in table-driven testing, though, the navigation data isn't contained in the table structure. In data-driven testing, only test data is contained in the data files.


• Hybrid Test Automation Framework - The most commonly implemented framework is a combination of all of the above techniques, pulling from their strengths and trying to mitigate their weaknesses. This hybrid test automation framework is what most frameworks evolve into over time and multiple projects.

While embarking on the automation project, it is essential to understand the pitfalls and limitation of test automation which are described beautifully in the classic paper of James Bach (1999) in ‘Test Automation Snake Oil’. For the successful implementation of test automation project, it should be treated as a separate project in its own sense and most importantly, it is essential to understand that automation can not and should not replace the manual testing, it should supplement the manual testing process.