Revision History: Table of Contents
Revision History: Table of Contents
Revision History: Table of Contents
Table of Contents:
Introduction
This document is aimed to provide a design for developing test automation suite for
testing BNYM – ADR Applications (Both Master File (MF) and Corporate Actions (CA))
using Quick Test Professional v9.5 (QTP).
1.1 Purpose
The purpose of this document is to address the test automation framework for BNYM
– ADR Applications Regression Test Suite. The coverage includes automation
framework design, folder structure, reusability plan and coding guidelines.
1.2 Scope:
This document focuses on the Automation Framework that shall comprise of:
Function library where generic and application specific reusable functions are
created and maintained
Test Data Sheets where test data are created and maintained. This will
contain data that needs to be entered in to application and expected results if
any.
Shared object repository where object properties and values are created and
maintained.
Script repository where automated test scripts are created, organized and
maintained specific to the Application functionality
Reusability, Maintainability and Extensibility with Resiliency
It will not discuss the specific architectural decisions and mechanisms i.e. the
detailed architectural specifications required for the actual implementation. Specific
architectural decisions here are at very granular level i.e. at the script level, the
related script interactions, specific libraries, their implementations and their usage.
In nut shell, the framework deliverable doesn’t focus on detailing the artifacts at the
test case and script level. The focus here is, depicting the place-holders for test-data,
function-libraries, modularity with significant exemplification using couple of
examples only. It also depicts the extensibility and resiliency considerations of the
framework. The detailed artifacts are nothing but the test scripts by themselves
which are deliverables of the Construction phase and have a separate acceptance
criteria for the same. Framework is a strategy deliverable out of the Elaboration
Phase.
The following constitutes for the hybrid framework proposition for ADR application.
Functional De-composition: Each of the ADR applications is broken in
to different functions to form a library (e.g. Search, Filter, Upload, etc.)
Data driven approach: This approach is used to input the value into
the ADR Application (UserID, Password, search criteria, search result headers,
etc) using data sheet.
Keyword driven approach: Sometimes it may be required to
parameterize the Browser, page and controls (Push button, combo box, check
box) logical names or physical descriptions (mapped with QTP’s object repository)
along with the operations on controls (Click, select, Search, Clear). Such
parameterized values may be maintained in excel data sheet.
The benefit of this approach is the ability to re-use functions across ADR application
modules. In addition, the functions can be easily maintained in case of any functional
enhancements / modifications to future releases of Enterprise Suite and allows
leveraging the modules / scripts into future releases. An intuitive and efficient test
management strategy to organize scripts, Libraries, Object repository and Data files
is adopted which aims to create a framework and lay the foundation of the testing
workflow.
This component will contain reusable functions for basic controls operations, Error
handling and error log functions. These basic functions will be used in Application
specific function libraries and automated scripts.
Some of the functions that act on controls/objects of the application like text box,
check box, radio button, window etc. are given below.
Sl.
Function
No Description Input Parameters
Name
.
1 invoke_URL Function to invoke the web application Bank Of Newyork URL
having the URL as a reference Address
2 fnc_wait Function To wait for a object in the Object Name
application
3 Login Function for logging onto the Username and Password
application.
4 logoutfromAp Function for log out from the BrowserName, PageName
p application
5 FormatInput Function for removing the blank spaces param_array - an array of
and converting the string to lower case parameters
6 Click_WebEle Function for clicking on the Objects on Browser Name, PageName,
ment the web page WebElement Nam
7 Select_Menu Selecting the Menu by passing the Browser Name, PageName,
menu path ( ; is delimitter) WebElement Name
8 Click_Button Function to check if a Web button is BrowserName, PageName
enabled or disabled and Button name
9 set_WebEdit_ Function to check if a string value can BrowserName, PageName ,
Value be entered in an edit box Editbox name and Value
10 select_Comb Function to check if value can be BrowserName, PageName ,
o_Value selected in a combo box combobox name , select
value
11 get_WebElem Getting the data from a web table BrowserName, PageName
entData Webtablename,
Row,Column
12 compare_Me Functtion to check if two messages Message 1 and Message 2
ssage are matching or not
13 verify_WebTa to check if the error message displayed BrowserName, PageName ,
ble_Validatio is correct and has all the mandatory WebTable name and Error
nMessage fields to be filled Message to be verify
14 get_WebEdit Function to check if tvalue can be BrowserName, PageName
Sl.
Function
No Description Input Parameters
Name
.
_Value taken from an edit box and Editbox name
15 click_Image Function to check if the image can be BrowserName, PageName
clicked on a web page and Image name
16 validate_Che Function to c heck if a check box can BrowserName, PageName
ckbox be selected or not and Checkbox name
17 select_Check Function to select a checkbox BrowserName, PageName
box and Checkbox name
18 ExecutionLog This function is to Delete the execution <filespec> filename path
FileDelete file
19 Execution_lo This function is to capture the a) <iStatusLevel> Name of
g execution results. the browser as specified in
application map
b) <sMessage> The
Message to specify what
exactly happens at that
point of time.
c) <iStatusLevel> Result of
the current Execution.
20 Verify_Flag Verify Flag image is existing or not BrowserName, PageName
and Image name
21 Verify_FlagN Verify Flag image is existing or not BrowserName, PageName
otExists and Image name
22 captureScree This function is to capture the Nil
nshot screenshot of the error.
23 createAlphan This function is used to Create Random <intsSize>: The Size or
umericString AlphanumericString length of the generated
String
24 closeInternet This function is to closing unexpected BrowserName, PageName
Exp_Window internet Explorer window and ButtonName
25 CreateRando This function is used to Create Random <intsSize>: The Size or
mString String length of the generated
String
26 timeDifferenc This function is to identify the a) <strInterval> - Types of
e difference between two dates. interval like "yyyy" for
year, "m" for mpnths and
"d" for days
b) <strDate1 and
strDate2> - Two dates to
compare
27 select_Radio This function is to select a Radio Browser Name, PageName
button Button. and Radiobutton Name
28 add_Number This function is used to Add the intDays ( No of Days to be
ofdays_To_c Number of Days to the Current Date Added or removed)
urrentDate and it will return the Calculated Date.
29 pageCheck_ This function is to check it the WebEdit BrowserName, PageName
WebEdit Elements are present in the current and WebEdit Elements
Page.
30 pageCheck_ This function is to check it the WebList BrowserName, PageName
WebList Elements are present in the current and WebList Elements
Sl.
Function
No Description Input Parameters
Name
.
Page
31 pageCheck_ This function is to check it the BrowserName, PageName
WebTable WebTable Elements are present in the and WebTable Elements
current Page.
32 DeletingFile This function is to delete a file if it The Path of the File to be
Exists. deleted
33 chkFileExist This function is to check if a file exists Path of the File to be
in a particular path. Checked
34 operation_on This function is to perform specified BrowserName, PageName,
_FrameObjec operation on object within a frame. FrameName, ObjectType,
ts_WithName ObjectName and Value that
need to be Entered.
Some of the functions specific to the ADR Application are listed below.
Sl.
Function
No Description Input Parameters
Name
.
1 chkHomePag Check the ADR home page options BrowserName, PageName
e and Home Page Options
2 chkMFCAPage Check the MasterFile/CorporateActions BrowserName, PageName,
links and Welcome text Link Name and Version
details
3 chkCUSIPRep Check the header names in the Reports BrowserName and
ort PageName
4 chkCUSIPRep Check the four links available in the BrowserName and
ortLinks Report Page PageName
5 chkCUSIPSea Check the fields and values available in BrowserName and
rchCriteria the search criteria table in reports page PageName
6 chkPreDefine Check the fields and values available in BrowserName,PageName,
dReports the search criteria table in reports page Predefined report links
(string format with ;) and
Pre defined link name
7 CUSIPSearch This function is to enter the CUSIP BrowserName, PageName,
Criteria Search criteria WebListNames,WebEditNa
Sl.
Function
No Description Input Parameters
Name
.
mes
8 CUSIPReport This function is to enter the Filter BrowserName,
FilterCriteria Search Criteria PageName,LinkName,WebLi
stNames,WebEditNames
and ButtonName.
9 CUSIPReport This function is to enter the Sort BrowserName,
SortCriteria Search Criteria PageName,WebListNames
and Button Nam
10 CUSIPReport This function is to check for the BrowserName,
Filter_ClkButt existence of the Objects after clicking PageName,LinkName, Table
ons on Add or Delete Button. Name, WebEdit & WebList
Object ClassName and
Button Name.
11 WebElements This function is to get the Child BrowserName,
Count Objects. PageName,Table Name,
Objects ClassName & html
tag Name
12 CUSIPReport This function is to export the BrowserName,
_SaveExcel CUSIPReport into an Excel by clicking PageName,LinkName and
on the Save as Excel link. the Path where the Report
has to be saved.
13 HOLDRSearc This function is to enter the HOLDR BrowserName, PageName
hReports Search criteria for Reports.
14 SetDate_Hold This function is set the Date by BrowserName, PageName,
rOperation selecting the Date, Month and Year on FrameName, MonthValue,
a Frame Object in Holder Operation YearValue and DateValue
Report and Holdr Client Service Report
for Master File Application.
15 HOLDRSClien This function is to enter the HOLDR BrowserName
tServiceRepo Client Service criteria for Reports.
rts
16 HOLDRSOper This function is to enter the HOLDR BrowserName
ationReports Operation criteria for Reports.
The excel sheet will have only input test data. There will not be any excel file created
for output data. Output data here is only the result file, which will be generated after
script execution.
Different excel files will be created for Master File Profile & Reports, Corporate
Actions Profile & Reports and Administration. Inside the excel file, different sheets
will be used for keeping the test data related to different menu items like, Enterprise,
Company, Contacts, DR, etc. All the screens in a particular module/functionality are
to be analyzed and each field (like text box, dropdown list, radio button, check box
etc.) which requires variable data is to be identified. Each identified field will be a
column in the data sheet. The data related to a test case will appear as rows with
test case name.
A global excel file will be created which will contain list of all the scenarios for Master
File and corporate Actions. This spread sheet serves as configuration/driver file that
specifies the test scenarios to be executed. The main driver script will read the data
from this file and performs the execution accordingly.
This is the main component of the framework that contains the modular scripts for
each scenario of Master File and Corporate Actions. Each modular script will address
the execution of set of test cases related to a particular functionality/scenario of the
application like, CUSIP Search, HOLDR Search, Underlying bulk move, etc. The
modular scripts will use the application specific functions to form the scenarios. Each
modular script will read the data from corresponding excel sheet and executes the
test cases based on number of rows present in the test cases.
The automated modular script utilizes all the other components of the framework. A
general flow consists of following steps:
These modular scripts will be called by Driver Scripts
Loads the required Object repository, generic and application specific library
and excel file.
Calls the required functions from Function Library based on the test
case/test scenario.
Reads the input Test Data from corresponding Excel sheet
Uses Object Repository to identify the objects of the application and
executes the test cases
Test execution results will be written to Result Files
Script independency:
Some times, it may require that a test case may have dependency on another test
case. That is, test case ‘abc’ has to be executed before test case ‘xyz’ to meet some
pre-condition. Such kind of requirement calls for logical grouping of test cases that
are to be executed. To handle this situation, the pre-requisites for a test case will be
analyzed. Based on the feasibility, appropriate actions will be taken inside the test
script to meet the pre-requisite. So, entry point and exit point for any test case will
be the same (most of the time starts from login to the application and ends with
logout).
The test cases that are not feasible to execute independently will be analyzed further
and addressed during construction phase.
This component of the framework will contain the shared object repository that
stores the description of the ADR application objects like, Internet explorer browser,
page, text box, combo box, radio buttons, etc. This file can be accessed by multiple
test scripts and functions. All the required objects of the application will be added to
the object repository using QTP and the logical names generated by QTP will be
renamed to give meaning full names.
With the use of Shared Object Repository Test object information that applies to
many actions/functions is kept in one central location. When the objects in
application changes, we can update them in one location for all the actions and this
is one of the key advantages of using a shared object repository.
The file structure for storing the results of different releases for execution cycles is
depicted below.
Snapshot of the folder structure at a high level is given below, representing the
organization of automation assets.
ADR_Automation Folder:
All the Test Assets will be created and stored under ‘ADR_Automation’ root
folder. Path independent design enables you to place the folder in any path and
can start executing the scripts with little or no modification. The
‘ADR_DriverScript’ is placed under the root folder which will drive the script
execution.
Automation_Scripts Folder:
This folder contains 2 sub-folders, one for placing modular scripts specific to
Master File and the other for Corporate Actions application. Each modular script
will address the execution of set of test cases related to a particular
DataTables Folder:
This folder contains the excel files used to store test data related to the
application. Different excel files will be created for Profile and Reports section of
Master File and Corporate Actions. The Automation script will read the data
from respective excel sheet.
Function_Library Folder:
This folder will contain library files (*.vbs) which will have:
(i) Functions specific to Master File and Corporate Actions application.
(ii) Common utility functions and error handling functions used across the
application
Object_repository Folder:
Shared object repository (*.tsr) files will be stored in this folder. A shared
object repository stores test objects in a file that can be accessed by multiple
tests. There will be 2 object repositories one for the objects of Master File and
other for Corporate
Actions.
Results Folder:
After execution, the automated scripts will log the execution results in this
folder. The detailed and summary reports will be placed under this folder.
Basic failures:
These are the failures that occur at the system level (e.g. Data Table, Window
declaration file not loaded, library file not found, etc.).
Before opening any file, its existence in specified path will be checked. Every function
starts with checking for appropriate window. Utilities are developed for basic
functionalities like filling the text box, selecting radio button and selection from list
box. These utilities will check for existence and enablement of controls before doing
any operations.
If there are any such failures, the script logs appropriate message and continues
execution with next test case/scenario.
Application failures:
Failures corresponding to the application like Unexpected Pop up window, Page Not
found, server time-out etc. falls under this category. These kinds of errors will be
handled by Recovery scenario wizard of QTP. Different exceptions will be captured
and appropriate functions will be developed to handle each scenario. Whenever any
error occurs that interrupt the script execution, QTP automatically calls the recovery
mechanism which in turn calls the function to handle the exception.
The results of the last test run can be viewed in this file and it can be saved for
future reference. The name of the log file created can include the name of the test
run, version and build details of the application under test and the date of the
execution of the test. Thus a unique application log file can be created for each test
run.
The driver script will load Object repository, Library files and Master data
sheet.
Based on the ‘RUN_FLAG’, driver script will invoke appropriate modular
test scripts.
Each modular test script (scenario like CUSIP search, Underlying bulk
move, etc.) will load the appropriate excel sheet.
The test script will invoke application under test.
Based on the test script, fetch the appropriate data from the Excel sheet
and key in to the application under test.
Fetch the Actual value from application under test and verify with the
expected value either in excel sheet or inside the script
Display the Pass / Fail results or Log messages for each of the test step.
Result files will be saved in the appropriate folder.
4 Re-usability:
The activity of creating the framework (functions and sub-functions) will leverage the
automation scripts. The plan is to re-use the code (in terms of flows), parameterize
and fit it in to the designed framework.
The common utility library contains general functions like filling edit box, selecting
dropdown item, closing all windows, etc. This library will also contain the functions
for generating customized test reports. These functions can be reused while
developing application specific function library as well as in the automated scripts.
Most of the functions in this library can be useful in automation of any application
that uses similar technology.
The ADR application and test cases will be analyzed to identify the reusable
functionality. Appropriate functions will be developed for these functionalities that
can be used across whole application to automate test cases. The test script will
actually contains a series of calls to different functions and navigation logic based on
the test case.
The developed automation scripts will support reuse of same test data for repeated
execution cycles, provided there is no changes in the test specification. During
execution, the script checks for the existence of the test data in the application.
Appropriate actions will be taken by the script based on the requirement. The
implementation logic is illustrated with an example in the flow chart depicted below.