This document discusses implementing a hybrid test automation framework using QTP. It proposes using intermediate data tables to define test steps in a keyword-driven manner. An application map is used to dynamically create objects without an object repository. Component functions contain actions to perform on objects. A main driver script connects to tables to send intermediate tables and core engine files to a sub-driver script. Test results are logged to tables for reporting. The framework aims to have reusable, maintainable test automation with less programming expertise.

1. Hybrid Test Automation Frameworks
Implementation using QTP
Pallavi Patwa
"When developing our test strategy, we must minimize the impact caused by changes in
the applications we are testing, and changes in the tools we use to test them."
--Carl J. Nagle
Abstract:
Various white papers have been published on Test Automation framework however how
to implement the framework is the puzzle often faced by Test Automation Developer.
This article provides overview of how the hybrid test automation framework can by
implemented using QTP with example.
Need for Automation Framework
With the onset and demand for rapidly developed and daily deployed build, test
automation is crucial.
Test Automation is kind of development activity. And for the most part, testers
have been testers, not programmers.
To have faster cycle time for development of test automation with less expertise,
use of application-independent test automation framework becomes inevitable.
Automation Frameworks
Various automation frameworks are available viz
• Data Driven Automation Frameworks
• Keyword Driven Automation Framework
• Modular Framework
• Hybrid Test Automation (or, "All of the Above")
Implementation of Hybrid Test Automation framework using QTP is discussed in this
article

2. Hybrid Test Automation Framework Architecture
Diagram 1
Let us start with Intermediate tables which are based on keyword or test driven approach.
Here the entire process is data driven including functionality. The keyword controls the
processing.
Spreadsheet has been used as a mean for Intermediate data table. The records in data
table contain the keywords that describe the actions we want to perform. They also
provide any additional data needed as input to the application.
Consider following example
• Invoke browser, provide username / password & click sign on.
• Check if user have entered correct username /password, if not instruct to provide
correct username/password.
• After providing correct username and password, click ‘Yes’ on the warning
screen to proceed further.
• In end check if user has successfully logged in home page.
For above test case, consider following data table record as seen in Table 1

3. Table 1
Brief explanation of Table 1:
Based on keyword contained in Component column i.e. Web, the Web related functions
will be called.
Any object in QTP is identified primarily by its parent child relationship. So Browser
column contains the name of Parent Browser in which object reside.
Object column contains child object in the Browser on which action needs to be
performed. Object name is the name of the object or unique identity of the object E.g. for
object like Web Element; it may not have its name as unique identity so html tag & class
have been taken as unique properties to identify the object. The unique identity of object
in object name column is required for creation of run time object from Application Map.
Action column contains action to be performed on the object. Here apart from generic
action i.e. set or click, this column also has keyword as ‘VerifyMinorError’. Based on
this keyword, the functions to check if user has entered correct username /password will
be called.
As name suggested Param column contains inputs for action to be performed.
Expected column contains expected value that needed to be compared with actual while
checkpoint column contains the user defined messages to be displayed in pass/fail report.
How this will be processed further
The Intermediate Tables are handled by the Sub Driver which passes each Step to the
Core Engine (consist of application map, component function, support function.vbs) for
further processing.

4. About Core Engine
The Application Map:
The Application Map is one of the most critical items in this framework. Since the
application GUI is not stable enough, so as suggested ‘Application Map file’ concept has
been implemented.
Application Map is a .vbs file consisting subroutines that create runtime object by using
Descriptive programming. With the use of application map file, creation of object
repository step has been omitted.
Consider the below snippet of code for implementing a Application Map file concept
Snippet 1
In above snippet 1 of code, Subroutine which accepts Object & Object name has been
declared. Initially Parent Objects i.e. Browser & Browser Page are created in this
subroutine. Afterward based on keyword in object column of Intermediate table, other
child objects are created.
The Component Functions:

5. Once the objects has been created using Application Map, next step is to perform action
on the object to drive the test script forward.
Component Functions are those functions that perform specific tasks (e.g. Invoke
application action, press a key or button, etc), also call “User Defined Functions” if
required.
In this automation framework various Component Functions for each type of object (e.g.
WebEdit, WebButton, WebElement, WebLink, etc...) have been clubbed in a single .vbs
file.
Consider the below snippet of code for Component Functions.
Snippet 2
In above snippet 2 of code, the Browser, Page & Child Object descriptions (derived from
Application Map) have been passed as parameter to the Component function. Apart from
Object descriptions, the action which needs to be performed on these object along with
parameter required to perform the action has also been passed.
Expected value & user defined checkpoint message passed to these functions are in turn
passed to “User defined Function” for further comparison with actual value derived in
component function. E.g. refer fnWebElement Function in above snippet 2 of code.

6. Here, we can also add extra code to help for initial conditions; synchronizations apart
from those provided by the tool. E.g. refer fnBrowser Function in above snippet 2 of
code. In this function before invoking the application, open browser (if any) has been
closed.
The Support Functions:
The Support Function consists of generic functions with core logic. These functions are
independent of Test Automation Framework & can be also useful outside the context of
the framework. In this framework the Support Functions.vbs contains the general-purpose
routines and utilities that let the overall automation framework do what it needs to do.
They are the modules that provide things like
o File Handling
o String Handling
o Database Access
o Logging Utilities
o Error Handling Utilities
Consider the below snippet of code for Support Functions
Snippet 3

7. Snippet 4
While in Snippet 3 generic database functions to Execute SQL & Disconnect database
session have been provided, Snippet 4 provides the user defined functions which
compares actual with expected & log pass/fail messages or error correction messages in
Main Driver tables (For more details on Main Driver tables ref session Role of Main
Driver in Test Automation Framework ).
Role of Sub Driver in driving the Core Engine
After understanding the primary purpose of Core Engine (i.e. Application Map,
Component Function, Support Function) let us now understand how the Drivers (which
consist of Main Driver & Sub Driver) drives the core Engine. Let us first take look at the
role of Sub driver in driving the Core Engine.
Sub Driver in this framework is the QTP Script. Sub Driver script processes intermediate-
level tables listing Steps to execute. Sub Driver reads each record from the intermediate-
level tables and passes each Step to Core Engine it finds during this process.
Consider the below snippet of code for Sub Driver

8. Snippet 5
Snippet 6

9. In Snippet 5, Intermediate data tables & the Library Files are passed as the parameter to
Sub Driver. After processing, the Library Files are included in the script, while
intermediate table are read line by line until it reaches end of file. While reading every
row of intermediate data table, Sub Driver stores value/Keyword of each column in the
variable list.
In Snippet 6, When Sub Driver encounters the Component Keyword i.e. “Web” from
intermediate data table; it starts further processing for web related events. Firstly it passes
param list as the inputs to Application Map for creation of runtime objects. Afterward
based on object keyword, it invokes the corresponding Component Function module to
handle the task
Role of Main Driver in Test Automation Framework
Main Driver mainly deals with the entire set up required before running the individual
test scripts The Driver Script consists of the following components, which are plug and
play units.
Driver tables: - The Main Driver tables plays crucial role in this framework. Relational
database concept has been implemented while designing main driver tables. Main Driver
tables are ported in a separate schema created in Oracle Database.
Various tables are designed to hold data like the Core Engine File names that requires to
be included in Sub Driver Script, the intermediate data table i.e. spreadsheet names, the
sequence in which the intermediate data tables need to be sent to Sub Drivers (E.g. for
batch processing, after login.xls the Functionality Test 1.xls, the Functionality Test 2.xls
required to be sent in sequential manner to Sub Driver for further processing), etc
Apart from these tables, a special table named Audit Trail Table is designed to hold pass /
fail results logged after comparing expected vs. actual while processing the test script.
The idea being the development of the reporting tool that can represent data in Audit
Trail Table (For more details on this refer session Reporting Tool).
Library Functions: - For reading data from Driver tables, Support Library Functions
(that consist database handling functions) are included in the Main Driver script.
Initialization.vbs:- The initialization.vbs in this framework is used to declare and define
the variables which are not going to changes frequently e.g. schema name/ password for
the main driver tables, the sequence list for the intermediate tables, etc. The idea being at
any point of time, the script executor should not require to interfere the Main driver code.
Initialization.vbs is also included in the Main Driver Script
How Main Driver will work?
The main driver script connects to driver tables, reads data like Core Engine file/
Intermediates data file name, creates absolute path for these file names & sends to Sub

10. driver as parameter. After Sub Driver completes processing of first intermediate data
table, the control returns back to main driver which is now ready to send the next
intermediate data table for further execution.
Reporting Tool
Reporting Tool is the interesting plug & play feature for this Test Automation Frame
work. Here reporting tool are simple .jsp pages that represent data logged in driver table
(viz: pass/fail results with user defined check point, start & end execution time of the
script, etc) in html format. The advantage being the viewer can get online status of script
execution, pass/ fail result on internet. Special feature like export to excel can be also
added to this reporting tool.
In Nutshell
We have seen the features of implementation of Hybrid Test Automation framework
using QTP; let us now recapture implementation of Automation Framework work flow
from start.
The flow starts with the Main Test Driver Script. The Main Driver Script first loads the
support functions & variables available in Initialisation.vbs file e.g. schema name/
password for the main driver tables, etc
Main Driver Tables are repository built in Oracle database that consists the information
such as Core Engine File names, the intermediate data table i.e. spreadsheet names, the
sequence for processing of the intermediate data tables, etc.
Main Driver Script connects to Driver tables with the help of support functions &
variable list available from Initialisation.vbs, reads data from Driver tables & sends the
same as parameter to Sub Driver Script.
The interaction logic with AUT has been depicted in Intermediate Data tables i.e.
spreadsheet in the form of keyword. Sub Driver Script after including Core Engine files
(consist of Application Map, Component Functions, Support Function), reads each record
from intermediate data tables and store the same in variable list.
Application Map is a .vbs file consisting subroutines that create runtime object by using
Descriptive programming. Sub Driver passes the variable list i.e. each record read from
Intermediate data table to Application Map for creation of run time object. Based on
keyword/ value available in variable list the Parent as well as child object required to
execute the test steps are created.
Once the objects has been created using Application Map, next step is to perform action
on the object to drive the test script forwards. Component functions consist of low level
events (i.e. press button, set param in input boxes) to be performed on the object.

11. Sub Driver passes the object description (derived from Application Map) along with
action to be performed & parameter required for performing action as inputs to
Component Functions. Based on object name & action to be performed the corresponding
component functions are invoked to handle the task.
The Support Functions are functions with core logic which are independent of any
automation framework. These functions can be called from any module of framework if
required. Apart from providing generic utilities (e.g. Database Access utilities, Error
handling utilities, etc.), support functions also contain user defined functions viz sub
routine for comparing actual vs. expected & logging pass and fail result in Main Driver
Tables. The Pass/ Fail results logged in main driver tables are then represented in the
Form of Reporting Tool.
References
Test Automation Frameworks by Carl J. Nagle
About the Author
Pallavi Patwa is a Senior Technical Consultant at TechMahindra Ltd. She is a CSTE from
QAI and ISTQB Certified tester. She has about ten years of experience in the area of
software validation and verification and test automation