Test Automation Framework Approach

using Quick Test Professional

20.01.2011

Beena Praveen
IBM Global Services
e-mail: beenapraveen@in.ibm.com
Contents
Test Automation Framework Approach using Quick Test Professional...........................1

Contents ...............................................................................................................................2

Automation Framework .......................................................................................................1

Automation Framework .......................................................................................................1

Framework Features..........................................................................................................................1
Framework Features..........................................................................................................................1
Advantages and Benefits....................................................................................................................1
Advantages and Benefits....................................................................................................................1
Framework Components....................................................................................................................2
Framework Components....................................................................................................................2
Functions........................................................................................................................................2
Functions........................................................................................................................................2
Actions...........................................................................................................................................2
Actions...........................................................................................................................................2
Driver Script...................................................................................................................................2
Driver Script...................................................................................................................................2
Batch Script....................................................................................................................................2
Batch Script....................................................................................................................................2
Datasheet........................................................................................................................................3
Datasheet........................................................................................................................................3
Object Repository...........................................................................................................................3
Object Repository...........................................................................................................................3
Language Support...........................................................................................................................3
Language Support...........................................................................................................................3
Constants........................................................................................................................................3
Constants........................................................................................................................................3
The Development Environment..........................................................................................................4
The Development Environment..........................................................................................................4
Development Process.....................................................................................................................4
Development Process.....................................................................................................................4
Steps for Automating a Test Case – An Example................................................................................5
Steps for Automating a Test Case – An Example................................................................................5
Automation Framework
Automating tests by recording actions and playing the recorded scripts contained the hard-coded
value, which had to be changed if anything in the application changed. This activity of changing the
script when there is a change in the application not only resulted in unreliable scripts but also high
maintenance cost. Hence designing scripts independent of the application became very important. To
cater to these needs this automation framework was developed.

Framework Features
• The framework is a set of automated test cases that performs regression testing.
• The test suite also gives the flexibility to run specific tests.
• The test scripts within the tests can be reused across other tests without or few modifications.
• The flow within the test scripts is controlled by the values in the datasheet.
• The use of item key pair in the Actions makes it flexible to update any new changes to the screens.
• The reusable actions can be used by setting appropriate values to the environment variables.
• The framework contains library of reusable functions, which is easy to expand and maintain.
• The framework has a hierarchical architecture making it structured and modular.
• The functions are independent of data.
• The framework also supports testing the application in different languages.

Advantages and Benefits

• High degree of reuse within the application
• Additions, deletions, and updates to the functions are minimal
• Isolation of all layers –— Presentation, Language and Functions
• Object Properties can be changed without changing the script
• Flow can be changed without affecting the Object Properties
• New Languages can be added with minimal changes to the script

1 of 6
Framework Components

Functions
The function library mainly consists of generic functions and very few module-specific functions. These
are used to perform some basic tasks. As most of the applications revolves around performing
common tasks like entering values to the fields, comparing values, retrieving values from the fields,
clicking on links, images, and buttons, displaying messages, the generic functions can be reused
extensively.
In addition, the use of item key pairs for input and output parameters in the functions shields it from
frequent changes to the functions. Although most of the functions are very generic and can be reused
across the product or the application, some module-specific functions may be required to perform
some specific tasks. These functions are present in the common and module-specific VBScript files.

Actions
An action is the automated version of a test case. It is a pool of functions and reusable actions. It is a
script, which can be reused either across the module or across the application. Similar to functions,
there are generic actions and module-specific actions.
Generic Actions
Consider the task of resetting field values. This activity in turn has tasks like: retrieving the field values,
entering new values, clicking on the reset button and finally retrieving the new values and comparing
them with the actual values. As this function behaves the same across screens, the activity of resetting
field values can be reused across the screens. Similarly, this behaviour applies for activities like
clearing fields, selecting menu items, searching for records, sorting and navigation, validating
message display etc.
Module Specific Actions
Consider the scenario of logging into the application. This activity involves some generic activities
(setting values in some text fields). These generic activities consist of reusable actions whereas the
tasks contain functions. This scenario highlights the reuse of an action in a different scenario.
Environment Variables
Environment variables are user-defined variables used to handle changes to the values of the
interface elements like screen name, table, link name, button name, field property, browser name,
frame name, page name etc. These variables are declared at the resulsable action level. The values
for these variables are set at the action level where the reusable actions are called and thease values
are retrived at the reusable action level.
The value of an environment variable remains the same, regardless of the number of iterations, unless
the value of the variable is programmatically changed in the script.
Note: The enviroment variables are extensively used for generic actions as module specific actions
are used as they are with few or no changes.

Driver Script
A driver script is made up of calls to one or more actions. Testing a business process or scenario is
done at this level. The input data for the scenario is provided here.

Batch Script
A super script containing calls for executing programs covering multiple business processes
collectively. The usage of a batch script is optional. It makes it easier to run several test cases in a
row. The batch script can be compared to the test sets as known in Test Director / Quality Center.

2 of 6
Datasheet
Data is the heart of any application. The success/failure of a Test Case is determined by the kind of
data that is used for testing the application. The purpose of a Data Sheet is to have data that will find
faults in the system. If such a volume needs to be accommodated, then the maintainability of such a
data sheet may turn out to be very high. To minimize the same, the concept of single data sheet is
used for each driver script. Multiple sheets within a single datasheet are used to support different
languages.
With this concept, all the input and output data are maintained as a single excel sheet. This gives the
flexibility of having the cells mapped so that any change in one cell data, which is common across, will
be reflected in the other cells also.
The datasheet has various rows and columns. The columns represent the various input and output
values (parameters). The datasheet provides both input and expected results verification.
The rows represent test conditions or data input. The driver script loops through the datasheet row-by-
row and executes the test condition by using the data in that row. A column with a name
“ScreenName” is defined. The value in the “ScreenName” column of the datasheet steers the
appropriate reusable action in the driver script. For example, the value Login in the column
“ScreenName” initiates the action Login in the driver script. The order of the rows is important as the
actions are steered in the same order.
Consider a scenario wherein you might want to:
• Add details of two products
• Edit the product details
• Delete the product details
In this case, the ScreenName value in the first two rows must have the value Products – Add. The
subsequent rows must have the values Products – Edit and Products – Delete.
A column with a name “ExpectedResult” is defined which holds various test conditions. A test
condition can include field validations, positive validation, and negative validation of the data in the
application.

Object Repository
The object repository is a collection of objects like links, buttons, tables, and fields. While executing a
test condition, these objects are recognized by QTP and mapped to the objects in the application
rendering the test as success/failure. However, the need to have all the objects in the repository is
eliminated. The object repository is shared and module-specific.

Language Support
Currently, the framework supports multiple languages. It can be customized to support any number of
languages with minimal changes. It is required to add a new sheet to the datasheet with the data
specific to the new language.
Use of descriptive programming and language-specific VBScript files eliminates the need to duplicate
the scripts and the objects in the object repository. Each language-specific VBScript file contains
variables representing the links, buttons, and screen names in the application. However, the values for
these variables are specific to the language. When the script needs to be executed in a particular
language, the language-specific VBScript file needs to be loaded.

Constants
The parameters like frame name, object properties (link, button type, field type) that do not change
frequently are captured in a central file. In the event of any change to the object properties, only the
central file needs to be updated. This approach eliminates the need to make the same changes in
multiple places thus ensuring maintainability.
The changes made to the Constants file must be reflected in the Automation scripts to ensure that the
scripts can be successfully executed.

3 of 6
The Development Environment

Development Process
This framework is an attempt to simplify and speed up scripting by making use of reusability. It is a
tiered organization of the function libraries. The functions are organized into separate libraries, to help
in keeping the functions more managed, thus ensuring reusability. These functions are classified
based on the modules in the e-Sales application.
Business scenarios are identified for each module. Each business scenario has several distinct
processes like log on and log off. Each process defines an activity. This activity is referred as an
action. Each action is drilled-down to the lowest level task. A navigation step in the application
constitutes a task. Each task defines a function in the function library and since these tasks can be
repetitive, the functions are reusable.
Several such tasks then constitute an action. Since some of the actions are common across the
application, these actions can also be reused.
This approach not only makes a complex process modular but also ensures reusability.
The following diagram represents the organization of the QTP scripts:

4 of 6
Steps for Automating a Test Case – An Example
Problem: A new user wants to register in rediff.com. The website supports multiple languages and it
needs to be tested for multiple languages too. This test needs to be automated.
Steps to automate the test
1. Define a test case “Register User”
2. Define a datasheet and make the test data-driven.

RegisterUser.xls

3. Define a properties file and capture field names and table names for the registration screen.
Example,
ROOTPATH = "C:\TestScripts\"
BrowserType = "iexplore.exe"
URL = "http://login.rediff.com/"
SheetName = "English"
MainBrowser = "Rediffmail"
MainPage = "Rediffmail"

EditHtmlTag = "html tag:=INPUT"

ListHtmlTag = "html tag:=SELECT"
ButtonType = “type:=button”
ResetType = “type:=reset”

***************Register User Screen Start *************************

If (ScreenName = "RegisterUser - Add") Then
LoginNameField = "name:=login," & EditHtmlTag
PasswordField = "name:=passwd," & EditHtmlTag
RetypePasswordField = "name:=passwd1," & EditHtmlTag
FirstNameField = "name:=fname," & EditHtmlTag
LastNameField = "name:lname" & EditHtmlTag
GenderField = "name:=gender" & ListHtmlTag
StateField = "name:=state" & ListHtmlTag
PinCodeField = "name:=zip" & EditHtmlTag
EducationField = "name:=edu" & ListHtmlTag
OccupationField = "name:=occupation" & ListHtmlTag
AlternateEmailField = "name:=emailaddress" & EditHtmlTag
End If
***************Register User Screen End *************************

4. As Button and Link names change with languages, capture these constants in the
corresponding <language> file.
Example,
RegisterMeButton = "name:= Register Me," & ButtonType
ResetButton = "name:= Reset," & ResetType

5 of 6
5. Identify and place all module specific functions in the module-specific VBScript. Functions that
can be used across the application can be placed in the generic VBScript. When the
desired function is not available, define the function based on the following guidelines:
• Decide the purpose of the function
• Provide a descriptive name for the function
• Determine input parameters
• Determine return values, if required
• Implement the function.
6. Reuse the Reusable Actions for frequently performed tasks like clearing and resetting the
fields, browsing records, login application, logout application etc.
7. Using the Reusable Actions and functions (common and module specific) build the specific
script Register User
8. Using the Reusable actions and specific script, build the driver script “Register”.
9. Execute the driver script.
10. View results in the Test Results file generated by QTP.

6 of 6