The most successful automation frameworks generally
accommodate both keyword driven testing as well as data driven
Hybrid is a combination of Functional Decomposition and Data
Modularity can be achieved by nesting the test scripts and using
library files to implement reusable components (Reusable Actions
Hybrid = Modularity + Data Driven
Frame work Features
Support multiple projects/Test Suites/Test cases
24/7 Automatic Regression Test Running Facility
Generates Email Reports
Generates Test Logs
Easy to Maintain
Screen Capturing Files
Easy to build automation for the project
No scripting skills required for End user
ARCHITECTURE OF A HYBRID FRAME WORK
file HTML and CSV Report
Test Script Sheets
Core Framework Layer
The Core Framework Layer Is independent to any application and can be reused for
automation of every web based application. Core Framework Layer Consists of the
following components that cab be reused across all Applications
The Application Layer consists of the following components that have to be filled with
Keywords and Test Data based on the test cases to be automated for given
Object Repository Files
Framework starts its execution by calling the scenario driver. Scenario Driver loads
Library File like Report Library and Keyword functions Library. This also loads Config
file which contains information path of the repositories, Path of the script files
etc.Apart from this Scenario driver also loads scenario file which contains the list of
scenarios and scripts to be executed
From the Loaded scenario file each scenario will be consider one after the other for
execution if execution is ‘Y’, then scripts under scenario will be executed. Else
Scenario Driver goes to the next scenario
The best part in our frame work is you can even control which test script to be
executes by defining the execution status as Y or N..If script execution status is Y
then corresponding script sheet will be loaded into automation tool and run each step
in the Test Script File. In Test Script File we will find many columns like Step, Object
Name, Object Type,Operation,TD_1,TD_2,TD_3 etc.Columns TD_1,TD_2 represent
the test data to be used in the Test Script. One more excellent feature about our
frame work is we can even control the test data to be used while script is executing.
User can specify the Test data Columns to be used in scenario file against the Test
Script in the column Test Data. User can specify each test data column to be used or
he can also specify the range of columns to be used
Corresponding to each keyword written in the test script we can find the Keyword
functions in Library File WEBkeywords.Script driver calls there Keyword Functions
and perform the operations on the object. Before we perform operation on the object
of any page we will set the page to be used with function setBrowserPage. This
function also loads the repository corresponding to the page since Page name is
same as object repository name. Other words we maintain one repository for each
While framework is executing status of each script execution will logged to the HTML
file which is stored in the results folder.Our results file is very detailed which contains
Scenario name, test cases executed for each scenario, description of test step
executed, Results of the test step PASS/FAIL. Results summary will also be stored
in CSV file along with detailed HTML report
Below is the Flow Diagram of frame work Execution
Start Scenario Driver Script Driver
Automation Work Flow
Scripts from QC
Scripts from QC
Upload Scripts &
Mapped To QC
Upload Scripts &
Mapped To QC
Actions or User
Actions or User
Create Test DataCreate Test Data
Formal selection of manual test cases for automation:
Decision will be been taken on what can be automated and what cannot be automated.
Selection of the test cases to be automated will be based on the business risk attached to each
Tests that need to run once and those that need frequent human intervention are usually not
worth the investment to automate and need not be considered for automation
Avoiding business scenarios where complex hardware is involved
Sample feasibility analysis report.
Report for a
Accessing Test Data
Test Data is defined in separate excel files for each application in Move
Test Scripts written in QTP will access the Test Data using QTP’s Data
Test data defined in separate excel files will be imported into QTP’s Data
Importing Test Data from external excel files will be done using an import
Following syntax used to import a sheet from test data.xls file to a sheet
in data table
Syntax : Datatable.ImportSheet “Location of TestData.xls file”,
“sheet ID in
Testdata.xls file” , “Sheet id/sheet name in data table"
Example: Datatable.ImportSheet “C:Testdata.xls”,3, “Login"
There are two types of Reusable Components
User Defined Functions
Reusable Actions and User Defined Functions are maintained in separate folders
for entire application.
The advantage of using Reusable Actions is that it can be easily debugged and
can use the intelligence feature of QTP IDE.
All common scenarios will be captured using Reusable actions.
Functions will be used for performing generic tasks e.g. like splitting a string, etc.
These tasks are application independent.
Environment files are also called as initialization files or configuration files.
Environment files are created in external files with .xml format
Create Environment variables to access information like Server Name,
username, password, library files and Test Data.
This file can be used across all the called Actions and in all the Test Scripts.
Throughout the test the value of an Environment Variable remains the same.
Main Test Runner Structure
of each Module Test ResultsTest Results
Main Test RunnerEnvironment File /
User defined functions
New Change Request
Cases as per
New / Modify
New / Modify Master
Test ResultsTest Results
Test Data for the
Reusable ActionsReusable Actions
User defined Functions
Exception Handling: Recovery Scenario
Exceptions are conditions which stops test script execution
Exceptions might occur at any time during script execution
Exceptions in QTP can be handled by using any one of the
following two methods
i) Recovery Scenarios
ii) On Error Resume Next statement
Recover Scenarios will be implemented on all the modules.
Recovery Scenarios can be defined using Recovery Scenario
Manager in QTP.
Application specific Recovery Scenarios like recovery from
security warning, unknown pop-ups etc will be defined using
Recovery Scenario Manager
Reporting Test Result
Results of the Automation Scripts will be reported using Reporter Utility object
Results are reported at test case level and at every important state of the application.
Syntax: Reporter.ReportEvent <status>,"Scenario/Case Name“ ,“Scenario/Case
Status can be either micpass or micfail or micdone or micwarning
Example: Reporter.ReportEvent micPass,"Login Scenario","Auditee Logged In
Sample results snapshot that is reported using Reporter.ReportEvent statement is