Selecting the test automation framework

Automated test workloads are flawed based on the use of only one capture tool, such as IBM Rational®robot, to record and replay test cases. Using only one of the capture tools to run complex and huge tests is time-consuming and expensive. Because these tests are created randomly, their functionality is difficult to track and reproduce, and maintenance costs are very expensive.

For a start-up automated Test team, the better option is to use a test automation framework that defines a collection of assumptions, concepts, and working platforms or practices that support automated testing. In this article I tried to automate some of the test automation frameworks that I am familiar with-especially the modular test scripts, the test library architecture, the keyword driver/table-driven tests, data-driven tests, and hybrid tests. I'm not going to evaluate which frameworks are better or worse, but just provide some tips on how they are described and demonstrated, where they apply, and how to implement them using the IBM Rational toolset.

Test Script Modular Framework (the test scripts modularity framework)

The test script modularity framework requires the creation of small, stand-alone scripts that represent modules, parts (sections), and functions that are capable of representing the test application (application-under-test). These small scripts are then composed of larger tests in a hierarchical way to implement a specific test case.

In all the frameworks I will mention, this framework should be the easiest to master and grasp. It is a well-known programming strategy to build an abstraction layer in front of a part to hide the other parts of the application. It separates applications from modifications in parts and prescribes modularity in application design. To improve maintainability and scalability of the Automated test Suite (test suite), the testing Scripting modular framework applies the principles of abstraction or encapsulation.

To demonstrate the application of this framework, I take an example of a simple test case (figure) that tests its basic functionality (add, subtract, multiply, and divide) in the automated Windows Calculator program.

The lowest level of the script hierarchy is a standalone subtraction script. The first script below is addition, and the second is subtraction.