Test Automation Frame Work

This document aims at providing state of the art methodology for test automation and guidelines
to automate manual testing process currently in use. This requires that a formalised "manual
testing process" currently exist in company or organisation. The basic requirements for starting
automation process are

1. Detailed test cases, including predictable "expected results", which have been developed
from Business Functional Specifications and Design documentation

2. A standalone Test Environment, including a Test Database that is restorable to a known

constant, such that the test cases are able to be repeated each time there are modifications
made to the application

Key reasons for the success of the Automation

1.Selection of proper tool.

2.Selecting proper methodology for Automation.

3.Trained Automation Engineer.

4.Proper Automation environment (hardware and software)

Different Automation Methodologies available

1. The "Key-Word Driven" or "Test Plan Driven" Method

2. Fuctional Decomposition Method.

1. The "Key-Word Driven" or "Test Plan Driven" Method: The main concept behind the
"Functional Decomposition" script development methodology is to reduce all test cases to their
most fundamental tasks, and write User-Defined Functions, Business Function Scripts, and
"Sub-routine" or "Utility" Scripts which perform these tasks independently of one another. In
general, these fundamental areas include:

The design of Functional Decomposition Method is as follows

Driver Script

Test Case Test Case User defined

Script1 Script2 Function Script

Business Function
Data File1 Script Subroutine
Script

Data File2
 · Driver Scripts:
Perform initialisation (if required), then call the Test Case Scripts in the desired order.
· Test Case Scripts:
Perform the application test case logic using Business Function Scripts
· Business Function Scripts:
Perform specific Business Functions within the application;
· Subroutine Scripts:
Perform application specific tasks required by two or more Business scripts;
· User-Defined Functions:
General, Application-Specific, and Screen-Access Functions;

Advantages:
1. Utilising a modular design, and using files or records to both input and verify data,
reduces redundancy and duplication of effort in creating automated test scripts.
2. Scripts may be developed while application development is still in progress. If
functionality changes, only the specific "Business Function" script needs to be updated.
3. Since scripts are written to perform and test individual Business Functions, they can
easily be combined in a "higher level" test script in order to accommodate complex test
scenarios.
4. Data input/output and expected results is stored as easily maintainable text records. The
users expected results are used for verification, which is a requirement for System
Testing.
5. Functions return "TRUE" or "FALSE" values to the calling script, rather than aborting,
allowing for more effective error handling, and increasing the robustness of the test
scripts. This, along with a well-designed "recovery" routine, enables "unattended"
execution of test scripts.

Disadvantages:
6. Requires proficiency in the Scripting language used by the tool (technical personnel);
7. Multiple data-files are required for each Test Case. There may be any number of
data-inputs and verifications required, depending on how many different screens are
accessed. This usually requires data-files to be kept in separate directories by Test
Case.
8. Tester must not only maintain the Detail Test Plan with specific data, but must also
re-enter this data in the various required data-files.
9. If a simple "text editor" such as Notepad is used to create and maintain the data-files,
careful attention must be paid to the format required by the scripts/functions that
process the files, or script-processing errors will occur due to data-file format and/or
content being incorrect.

3. The "Key-Word Driven" or "Test Plan Driven" Method: This method uses the actual Test
Case document developed by the tester using a spreadsheet containing special "Key-Words".
This method preserves most of the advantages of the "Functional Decomposition" method,
while eliminating most of the disadvantages. In this method, the entire process is data-driven,
including functionality. The Key Words control the processing.

Here the application functionality is divided in to smallest functions. Utility scripts are written for
these functions. A standard Test case document is written containing sequences of utility script
and required data and verification data. Utility scripts are executed one by one to perform &
check required functionalities.
Architecture
Detail Test
Driver Script Controller Plan
Script

Utility Script

User Defined
function

The architecture of the "Test Plan Driven" method appears similar to that of the "Functional
Decomposition" method, but in fact, they are substantially different:
· Driver Script
· Performs initialisation, if required;
· Calls the Application-Specific "Controller" Script, passing to it the file-names of
the Test Cases (which have been saved from the spreadsheets as a "tab-
delimited" files);
· The "Controller" Script
· Reads and processes the file-name received from Driver;
· Matches on "Key Words" contained in the input-file
· Builds a parameter-list from the records that follow;
· Calls "Utility" scripts associated with the "Key Words", passing the created
parameter-list;
· Utility Scripts
· Process input parameter-list received from the "Controller" script;
· Perform specific tasks (e.g. press a key or button, enter data, verify data, etc.),
calling "User Defined Functions" if required;
· Report any errors to a Test Report for the test case;
· Return to "Controller" script;
· User Defined Functions
· General and Application-Specific functions may be called by any of the above
script-types in order to perform specific tasks;

Advantages:
This method has all of the advantages of the "Functional Decomposition" method, as well as
the following:
10. The Detail Test Plan can be written in Spreadsheet format containing all input and
verification data. Therefore the tester only needs to write this once, rather than, for
example, writing it in Word, and then creating input and verification files as is required by
the "Functional Decomposition" method.
11. Test Plan does not necessarily have to be written using Excel. Any format can be used
from which either "tab-delimited" or "comma-delimited" files can be saved (e.g. Access
Database, etc.).
12. If "utility" scripts can be created by someone proficient in the Automated tool’s Scripting
language prior to the Detail Test Plan being written, then the tester can use the
Automated Test Tool immediately via the "spreadsheet-input" method, without needing to
learn the Scripting language. The tester need only learn the "Key Words" required, and
 the specific format to use within the Test Plan. This allows the tester to be productive with
the test tool very quickly, and allows more extensive training in the test tool to be
scheduled at a more convenient time.
13. If the Detail Test Plan already exists in some other format, it is not difficult to translate this
into the "spreadsheet" format.
14. After a number of "generic" Utility scripts have already been created for testing an
application, we can usually re-use most of these if we need to test another application.
This would allow the organisation to get their automated testing "up and running" (for
most applications) within a few days, rather than weeks.

Disadvantages:
1. Development of "customised" (Application-Specific) Functions and Utilities requires
proficiency in the tool’s Scripting language. Note that this is also true of the "Functional
Decomposition" method, and, frankly of any method used including "Record/Playback".
2. If application requires more than a few "customised" Utilities, this will require the tester to
learn a number of "Key Words" and special formats. This can be time-consuming, and
may have an initial impact on Test Plan Development. Once the testers get used to this,
however, the time required to produce a test case is greatly improved.
3. This method involves writing key words for the smallest functions. We may have to spend
lot of time in identifying the key words. If the application is big the unit functions become
very large in number and it becomes difficult to maintain the scripts.

3.Another approach (deviation) from Test Plan Driven Method:

The new approach involves identifying the independent activities. Create main sequence for
every independent activity. Identify sub sequences in the main sequence.
Write functions for every sub sequence. Write functions for every test case in the sub sequence.

Identifying Sequence, Sub Sequence and functions

Sequence: Main function, which performs independent activity. Ex Registration.

Sub Sequence: Function, which leads to next level of function.

Function: Represent validation function for every field present.

Architecture

Library Variables
Functions

Driver Script Detail Test

Plan
 Report

Detail Test Plan

Action Script to be called along with verification Input1 Input2

Function

S1 Main Sequence 1 starts here

S1-1 Sub sequence 1 in main sequence S1

S1-2 Sub sequence 2 in main sequence S1

F1 Unit function to perform unit testing in a

Sub sequence

S1-3 Sub sequence 2 in main sequence S1

S2 Main Sequence 2 starts here

S2-1 Sub sequence 1 in main sequence S2

F1 Unit function to perform unit testing in a

Sub sequence

F2 Unit function to perform unit testing in a

Sub sequence

F3 Unit function to perform unit testing in a

Sub sequence

S2-2 Sub sequence 1 in main sequence S2

Driver Script reads the detail Test Plan line by Line. It calls the main sequence function first.
Then call the sub sequence functions. In every sub sequence function it calls unit functions,
which are independent of each other and perform unit function. If a function in sub sequence fails
the next function is called. If a sub sequence function is failed execution goes to next main
sequence.

The logical flow of the execution is as follows:

S1 P S1-1 F1 P,F F2 P
S1-2
 F
F

S2 P S2-1 F1 P,F F2 P
S2-2

Key Features

1.Verification functions are part of the main script.

2.A standard Test Plan is written.

3.A standard out put format for report generation.

4.Inupt data and verification data are part of the Test Plan .

5.Single sequence or group of main or all sequences can be executed .

6.A single test case, scenario or group of test cases can be executed .

7.New Sequences or unit functions can easily be added to the test plan.

Advantages

The Detail Test Plan can be written in Spreadsheet format containing all input and
verification data. Therefore the tester only needs to write this once, rather than, for example,
writing it in Word, and then creating input and verification files as is required by the "Functional
Decomposition" method.

Test Plan does not necessarily have to be written using Excel. Any format can be used from
which either "tab-delimited" or "comma-delimited" files can be saved (e.g. Access Database,
etc.).

If "utility" scripts can be created by someone proficient in the Automated tool’s Scripting
language prior to the Detail Test Plan being written, then the tester can use the Automated
Test Tool immediately via the "spreadsheet-input" method, without needing to learn the
Scripting language. The tester need only learn the "Key Words" required, and the specific
format to use within the Test Plan. This allows the tester to be productive with the test tool
very quickly, and allows more extensive training in the test tool to be scheduled at a more
convenient time.

15. If the Detail Test Plan already exists in some other format, it is not difficult to translate
this into the "spreadsheet" format.

16. After a number of "generic" Utility scripts have already been created for testing an
application, we can usually re-use most of these if we need to test another application.
This would allow the organisation to get their automated testing "up and running" (for
most applications) within a few days, rather than weeks.

The driver script, which performs the basic logic of driving the test plan, can be written
can be written only once for every tool and can used for all projects using the same tool.
New functionalities can easily incorporated by adding new sequences to the Test Plan.