1. Introduction
The way software industry moved from manual
testing to test automation, it is now moving towards Business Process
Automation. Business Process Automation works towards making automation
frameworks more and more meaningful to the Functional Subject Matter Experts by
involving them in Test Automation as much as possible thereby making Test
Automation business driven. To keep pace with the latest trends in the industry
and to have an edge over its competitors, it is important for a testing
organization to adapt itself to this new approach. One tool which is in line
with this approach is Mercury’s Business
Process Testing. Being Industry’s first web based test design solution; BPT
is one step further to the Keyword Driven Test Automation approach.
For any Software Testing Organization,
moving to a new tool like BPT is a big step. For it to justify this big step,
it is important for the organization to have successfully implemented the
Keyword Driven Test Automation Approach. This is because, it is easy for a
project to implement BPT if it is already following keyword driven approach
than for a project which is not. One of the benefits of using this approach is the automation effort saved due to reusability of the
keyword components across different applications. This benefit is realized when
the extent of reusability is high. This is possible when the type (eg. Web, VB,
SAP, Delphi etc) is common across applications to be automated, because keyword
components built with a particular QTP/WinRunner Add-in can be reused only with
applications that can work with that Add-in.
Today, most organizations are developing
web based application as against client server or mainframe applications. In
some instances, organizations are converting their applications from legacy
systems to web. Considering all this, it makes business sense for Testing
Organizations to go for Keyword Driven
Test Automation Framework for Web-based applications.
2. Purpose
This document is an attempt to build a
Keyword Driven Test Automation Framework which can be used across different web based applications. In this approach, the
endeavor is to build a lot of application independent reusable keyword
components so that they can directly used for another web application without
spending any extra effort. With this framework in place, whenever we need to
automate a web based application, we would not need to start from scratch, but
use the application independent keyword components to the extent possible and
create application specific components for the specific needs.
3. Framework Structure
The framework consists of the following
components.
·
Function
Library
·
Object
Repository
·
Database
·
Application
Scenario Files
·
Initialization
VB Script
·
Sequence
File
·
Driver
Script
·
Test
Case List File
The directory structure in which these
components are arranged is as shown below.
|
|
|
|
|
|
|
|
|
|
3.1. Function Library
In
this approach, all the coding logic is in the form of user defined VB script
functions. All of these functions are stored in function libraries (vbs file).
There is absolutely no scripting done outside of the function library except
for the Driver Script (explained in section 3.7). For each application, there
are two function libraries, one
which contains all the application
independent functions (or common functions) and another that has application
specific functions. While developing scripts for an application, the
endeavor would be make use of the application independent functions as much as
possible. In case, some functionalities require application specific functions,
create them and put them in the application specific function library.
The
common function library has a function (ExecuteScenarioFile) which reads the
keywords, objects and other parameters from the Scenario File (described later
in this document) and makes calls to appropriate functions in the function
library. This is the only function which is called from outside of the function
library (this function is called from the Driver Script).
Some
of the common functions that can be created for web applications are as given
below,
- Close all browser windows and launch a new instance of browser.
- Click on a Web Button with all error handling.
- Enter data in a Web Edit object with all error handling.
- Import data from MS Access to run time data table.
- Verify text on a Web page with all error handling.
All
the function library files (.vbs files) are kept in the Function Library folder
in the directory structure.
3.2. Object Repository
Each
application automated has a different object repository file and there is only
one object repository for each application. All the object repository files
(.tsr files) are kept in the Object Repository folder in the directory
structure.
3.3. Database
All
the test data is stored in MS Access database. The database structure is
designed in such a way that there is more or less one table for each screen on
the application. Almost every table has Test Case Id as one of the columns and
is either the only primary key or one of the primary key columns. The Test Case
Id represents a record or the data used for iteration. The database might have
100 sets of data, but the user might want to execute only 10 of them. The Test
Case Id helps in this situation by providing the user with the option to select
only certain sets of data.
The
connection to this database is established from QTP by creating a System DSN
for the database and using this DSN in the script. Ideally, we might want to
have one database file created for each application. But, we can also have one
database for multiple applications to save disk space.
All
the database files (.mdb files) are kept in the Database folder in the
directory structure.
3.4. Application Scenario Files
An
application scenario file is a spreadsheet which contains keywords, objects and
other parameters arranged in the desired order to form a test scenario. It is
from this file that QTP reads information and performs actions on the
application. This spreadsheet also serves as test scenario documentation,
thanks to the easy to understand and
English like keywords. Therefore, we do not need to have separate effort
spent for test case documentation thereby saving
time, effort and cost. It is this feature that makes the keyword driven framework so powerful.
The
application scenario file makes it very easy for the functional SME to create an automated
test by selecting keywords from the dropdown without any programming knowledge.
The
brains behind the keywords are the user defined functions which are called to
make it work for the SME. Let us understand this with an example,
The
keyword “Enter data” is used to
enter data into any field (WebEdit,
WebList or WebCheckBox) on any web page by passing appropriate objects and
parameters to the keyword. This is possible because of a function created to
read the keyword, objects and parameters from the application scenario file and
make calls to appropriate WebEdit, WebList and Web Check Box functions. So, we
can make a keyword reusable by making its building blocks (user defined
functions) reusable.
Therefore,
the key to saving automation effort
while following this approach is to create as many common web functions as possible, so that they can be reused to the
maximum extent.
Each
application has an application folder and all the application scenario files
(.xls files) belonging to that application are kept in the corresponding
application folder.
3.5. Sequence File
Sequence
File is a like configuration file which contains information required to do the
initialization settings to the Driver QTP Script for a particular application.
The Sequence File is in the form of a spreadsheet which has an entry for each
application and settings data such as Application Scenario file name, object
repository name, function library name, test case list for execution, the data
source, script development work area and script execution work area. Each
application has a “Run” or “Ignore” flag against it to say which application
scenario is to be executed. The Initialization VB Script (explained in the next
section) uses this spreadsheet to decide the application & scenario to be
executed, to get information about the Application Scenario file and do the
initialization settings for an application.
The
snapshot below shows how a sequence file looks.
The
Sequence File (.xls file) is kept directly under the root directory.
3.6. Initialization VB Script
The
Initialization VB Script is the starting point of script execution. It launches
QTP, sets the work area as development or production based on the user input
and does the following settings to the Driver Script.
- Set Work Area based on user input.
- Set the application scenario file for the current run.
- Set object repository.
- Set function libraries.
- Set data source.
- Set the test case list.
After
doing the above settings, it opens the Driver Script in read only mode for the
user to start execution. With this, the control is passed on to the Driver
Script.
The
Initialization VB Script (.vbs file) is kept directly under the root directory.
Note: The significance
of the Initialization VB Script is that it allows the user to run the same
script to do the initialization settings for different
web based applications.
3.7. Driver Script
Driver
script is a QTP test script which drives the script execution after taking
control from the Initialization VB Script. Strictly speaking; this is the only
script which is present as a QTP test script and not in the function library.
As mentioned in section 3.1, this test script calls the function
“ExecuteScenarioFile” which reads the keywords, objects and other parameters
from the Scenario File and makes calls to appropriate functions in the function
library. The beauty of this framework is that all the script execution is
covered by a single test and single QTP action.
The
Driver Script is kept directly under the root directory.
3.8. Test Case List File
Test
Case List File contains the list of Test Case Ids (explained in section 3.3 on
Database) to be executed in the current run. As mentioned in section 3.3, this
provides the user with the option to select only a subset of the data in the
database for execution of the current run.
The
Test Case List File is kept directly under the root directory.
4. Tips on developing a Strong & Robust Automation Framework
The
key to develop a strong & robust keyword driven automation framework is a
challenge for any testing organization. To make this happen and realize the
benefits of using it, the following guidelines are to be considered while
developing the framework using the approach mentioned in this document.
- Centralized Automation Team - One of the factors that stand out as a clear benefit in using this approach is the ability to reuse keyword components across applications thereby saving a lot of time, effort and cost. However, this calls for a lot of coordination between people doing automation in different projects. Therefore, it makes sense to have a centralized automation team working for different projects.
- Coordination Between Function and Automation Teams – Though this approach provides the functional SMEs with more flexibility to design the business flow to create automated tests, the Automation Teams still need to work closely with the functional SMEs to make them understand what each keyword does, how the object names map with the logical names in the object repository and the database structure. This calls for good coordination between both the teams.
- Creating right functions – The heart of the framework is the logic behind the functions in the function library. The way you design a function can make or break the whole framework. So, it is very important for the Automation Team to do proper analysis before creating functions. The endeavor should be to make the functions as generic as possible so that they can be reused across applications
- Script Maintenance – Even though changes in the application can be taken care of by updating the application scenario spreadsheet, it would be a good practice for the Automation Team to make sure that all of their functions are still good for use. Though this may not be a huge effort as in traditional automation frameworks, it might call for some work here and there.
No comments:
Post a Comment