TEST AUTOMATION FRAMEWORK
This section gives the introduction about test automation framework, various types of the framework and the analysis of the best suitable framework for the application under test (the application under test is referred as AUT). This also includes the detailed description of the format of the input (the input to the framework is referred as the test tables)that is given to our test automation framework.
1.1 RECORD/PLAYBACK MYTH
The test automation tool vendors market their product as the main feature of the tool is the ability to capture the user actions and later to playback them. Here is the basic paradigm for GUI-based automated regression testing – the so called Record/Playback method (also called as Capture/Replay approach)
1. Design atest case in the test management tool.
2. Using the capture feature of the automation testing tool record the user actions. The result is a macro-like script where each user action is presented.
3. Enhance the recorded script with verification points, where some property or data is verified against an existing baseline. Add delay and wait states points where the different actions aresynchronized.
4. Playback the scripts and observe the results in the log of the test management tool.
The basic drawback in this method is the scripts resulting from this method contain hard-coded values which must change if anything at all changes in our AUT. The costs associated with maintaining such scripts are astronomical, and unacceptable. These scripts are not reliable, even if theapplication has not changed, and often fail on replay (pop-up windows, messages, and other things can happen that did not happen when the test was recorded).
If the tester makes an error entering data, etc., the test must be re-recorded. If the application changes the test must be re-recorded. All that is being tested are things that already work. Areas that have errors are encountered in the recordingprocess (which is manual testing, after all). These bugs are reported, but a script cannot be recorded until the software is corrected. So logically nothing is tested by this approach.
So, avoid using "Record/Playback" as a method of automating testing. This method is fraught with problems, and is the most costly (time consuming) of all methods over the long term. The record/playback featureof the test tool is useful for determining how the tool is trying to process or interact with the application under test, and can give us some ideas about how to develop your test scripts, but beyond that, its usefulness ends quickly.
1.2 TYPES OF TEST AUTOMATION FRAMEWORKS
As we have eliminated Record/Playback method, let us explore about the existing automation methodologies. There areseveral test automation frameworks available, among these the selection is made based on the factors such as reusability of both the scripts and the test assets. The different test automation frameworks available are as follows,
Test Script Modularity
Test Library Architecture
Keyword-Driven or Table-Driven Testing
Hybrid Test Automation
1.2.1 Test Script ModularityThe test script modularity framework is the most basic of the frameworks. It's a well-known programming strategy to build an abstraction layer in front of a component to hide the component from the rest of the application. This insulates the application from modifications in the component and provides modularity in the application design. When working with test scripts (in any language orproprietary environment) this can be achieved by creating small, independent scripts that represent modules, sections, and functions of the application-under-test. Then these small scripts are taken and combined them in a hierarchical fashion to construct larger tests. The use of this framework will yield a higher degree of modularization and add to the overall maintainability of the test scripts....