TEST AUTOMATION GUIDELINES

AND
QTP BEST PRACTICES
 Name Org/Group Role Date
Prepared by: Pankaj Aggrawal NBCU Automation tester 9/5/2006
Reviewed by:
Approved by:

All document control issues pertaining to this document or for information about its
access and location please contact the following resource(s):

CONTACT INFORMATION

Name: Pankaj Aggrawal

Role: Automation tester

Org/Group: NBC Universal

Phone: *901-4047

E-mail pankaj.aggrawal@india.birlasoft.com

REVISION HISTORY

Section/
Version # Date Description of Changes Author
Page #
1.0 Initial Document Archana Marwaha
1.1 9/5/2006 1-22 QTP Pankaj Aggrawal

Test Automation Guidelines and QTP Best Practices Page 2 of 25 10/14/2008

 TEST AUTOMATION GUIDELINES AND QTP BEST PRACTICES

Table of Contents

.I Purpose..............................................................................................4
.II Automation........................................................................................4
What is Test Automation?.............................................................................................................. ......4
How….. ......................................................................................................................... .....................6
To ensure the success of test automation success one needs to “Think Past the Project and should
execute the project similar to the software development projects. To achieve this one needs to have
................................................................................................................................................ ............6
Plan the entire test automation effort........................................................6
................................................................................................................................................ ............7
Phase I – Pre-Planning .............................................................................................. .....................8
Phase III - Automation Process - Key Activities ............................................................................ ......8
Criteria to identify good automation hat is Test Automation?......................................................... ......9
.III General Guidelines...........................................................................10
.IV Quick Test Pro .................................................................................10
Purpose......................................................................................................................................... ....10
.V QTP Specific Best Practices.................................................................11
.VI Script Organization...........................................................................13
.A Coding Standards........................................................................... .....................13
.B Naming Conventions................................................................ ...........................18
.C Implementation...................................................................................... ..............20
.VII Function Libraries............................................................................21
.VIII Directory Structure.........................................................................23
.IX Version Control................................................................................23
.A Check In/Check Out.................................................................................. ...........23
.X Defect Tracking.................................................................................24
.A Defect Logging & Tracking...................................................................... .............24
.B Defect Flow Overview.............................................................................. ............24

Test Automation Guidelines and QTP Best Practices Page 3 of 25 10/14/2008

.I Purpose
The Process of building automated test script is similar to the process of software
development. Thus, Software Engineering best practices should be implemented to
ensure that the code is readable and comprehensive, maintainable and reusable
whenever possible. This document provides details of these Automaton Test Scripting
Best Practices.

The standards and best practices outlined in this document should be adhered to for
any test automation project.

.II Automation
What is Test Automation?

Software test automation is automating the steps of manual test cases using an
automation tool, to shorten the testing life cycle. As part of manual testing
same test cases have to be executed several times.

This might be true when application undergoes regression. Due to human error
some of the steps might be missed out or skipped. Automation helps to avoid such
human errors and also expedite the process. Implementing successful Test
Automation in an SDLC requires a detailed planning and effort. It is required to
think “Past the Project” prior to initiating the task of automation and have a clear
picture of final goal that has to be achieved. The below sections describe in detail
the approach and process to be followed to achieve an effective and optimized
solution for successful Test Automation.

Why…..

Automation saves time and effort which results in reduction of the Test life
cycle. Various test cases (including the data driven tests) can be executed using
the automation tool with minimal human intervention and effort thus resulting in
reduction of cycle time in test execution. Automation techniques can be made to
reduce / eliminate human intervention

Benefits of test automation are given below

Consistency of test execution and eliminating human error

Reducing cycle time of regression test cycles
Data driven testing
Earlier defect detection.
Faster Regression
Repeatability
Coverage
Reliability
Reusability

Test Automation Guidelines and QTP Best Practices Page 4 of 25 10/14/2008

 The graph below depicts the relationship between effort consumed in
automation vs. the time elapsed. A higher initial effort in building a test
automation effort results in a long-term benefit.

Complex functionality wherever possible should be automated. This leaves

enough time for testers to focus on the other granular tasks related to testing.
On other hand these scripts can be used to test the application more rigorously
thereby reducing the chances of any defects getting deployed into production.

When …..

Before initiating test automation one needs to evaluate whether it is a

viable/profitable solution. Automation life cycle is a subset of the entire test life
cycle and the same can be started during the initial phases of the Software
development life cycle. Automation planning can be initiated in parallel to the
test planning phase. To know more about activities performed in each phase
here Factors to be considered while deciding for automation

 Application is stable
It is essential that the Application under test (AUT) is stable enough to
develop an automated suite, else the effort that goes in for updating and
maintenance of the scripts goes very high.

 Number of regression cycles to be performed

In case testing is in its final phases of development or the number of
regression cycles to be performed is relatively low, then it is not advisable
to go in for test automation.

 Compatibility of Application Platform with Testing tools

Depending upon the Application platform and technology, there are various
testing tools available in the market. Rational, Mercury Interactive, Segue
Test Automation Guidelines and QTP Best Practices Page 5 of 25 10/14/2008
 and Compuware provide most of the popular testing tools. There are some
applications, which cannot be recognized using the available testing tools.
Thus the automation of such applications is not possible.

 Cost Benefit Analysis.

Good testing tools that can be used for developing an effective test suite
are expensive. The decision of initiating test automation also depends on
the factor if the organization is willing to make the necessary investments.
In certain cases it might be a viable solution however due to limitation on
time or cost it might not be an acceptable solution

 Availability of Skill team

Success of a Test automation project is a result of effective partnership
between the test automation team, manual testing team and the
development team. It has been observed during the past experience that
the manual testers have a fear of losing there jobs in case the test
automation is used for testing. Thus the goal of automation should be very
clear with in the team as support of the manual testing team would be
inevitable make “Test Automation” a success.

How…..

To ensure the success of test automation success one needs to “Think Past the Project
and should execute the project similar to the software development projects. To
achieve this one needs to have

 Clarity of what one wants to achieve thru automation.

 Executing the project similar to a software development project
 Take up test automation as a fulltime effort and not as sideline
 Plan the entire test automation effort
 Develop an automation approach, based on the project requirement and
CTQ’s of the customer
 Create test framework, which are application-independent
 Create test design & treat it as a separate entity from test framework
 Ensure the source code / scripts are properly managed & tracked
 Track defects in the automated scripts and test them before handing it over
to the testing team for execution.
 Develop help files/ support document for the test suite user.

Test Automation cycle needs extensive planning, development and implementation.

Based on the various activities to be performed the entire test automation life cycle can
be divided in to different phases. Each phase holds its own value in the test life cycle.
A standard Automation Process followed in any Test Automation project depicted in the
diagram below

Test Automation Guidelines and QTP Best Practices Page 6 of 25 10/14/2008

Test Automation Guidelines and QTP Best Practices Page 7 of 25 10/14/2008
 Phase I – Pre-Planning
 Perform the Gap Analysis to understand the existing scripts and client
CTQ’s / requirements.
 Application walk through
 Create the Traceability Matrix
 Review the existing manual test scripts.
 Rewrite unclear/ ambiguous test steps and convert them into modular
manual scripts.
 Ensure that the Application to be tested is stable enough to initiate the
development of automated scripts.
 Verify the availability of the test data (Application Data) in the backend.
Incase the data is not available in the application, prepare the valid
application
 Align manual scripts on proposed automation strategy
 Define expected results for each test step/ test case
 Prepare valid positive test data (script Data) for test steps wherever
required.
 Identify the smoke test manual test scripts set
 Identify the regression test suite.

Phase II - Test Automation Planning

 Create Test Automation Strategy

 Test Design
 Coding standard
 Naming Convention
 Test Automation Architecture for developing the automation framework
 Creation of Test bed
 Script design takes care of the concept of modularity and re-usability.
This is depicted in the diagram below:

Phase III - Automation Process - Key Activities

Some of the key activities that we perform as part of test automation are
listed below:

 Develop function libraries consisting of reusable functions, using the

automation tool, which can be saved in library files
 Prepare / maintain Test bed
 Develop the custom log file
 Identify the custom objects in the application and map them to a
standard object.
 Create test scripts based on the test steps available in manual test
scripts
 Identify and create the checkpoints and synchronization points to be
inserted in the scripts
 Connect to the database (Excel/database) and parameterize the scripts
for data driven testing
 Exception handling for the scripts
 Comments to ensure the readability of the scripts

Test Automation Guidelines and QTP Best Practices Page 8 of 25 10/14/2008

  Re-visit the traceability matrix to ensure the coverage between the
Automated test scripts and the Manual test scripts
 Debug scripts and ensure the smooth running of the scripts
 Do a peer review of the scripts
 Maintain the various versions of the automated test scripts using the
version control system.
 Create a test script file to call the automated test scripts in a specified
series to be executed in a batch mode
 Run the test suite in batch mode as per the execution plan
 Prepare the User Manual document to run the automated test scripts

Adhere to the above-mentioned steps to ensure a test suite that has the
following features

 Re-usability – Develop a robust function library to be used across the

projects and within the application.
 Robustness – Develop a robust test suite that can be easily used for
testing the application in different environments e.g. development,
testing and production.
 Portability – To ensure easy installation of the suite in different
environments.
 Modularity – Develop modular scripts to ensure maintainability,
scalability and readability of the scripts.
 Scalability - Scalable scripts which can be upgraded/ enhanced.
 Maintainability – The approach should be such where in major effort
goes in to the planning and developing the scripts where as least
possible effort is required to maintain the same.
 Data Driven Testing – To perform positive and negative tests using
data driven scripts.

Criteria to identify good automation hat is Test Automation?

The following points should be considered while identifying the good candidates for
automation

 Repeatable test scripts: - Test scripts to be executed repeatedly for smoke

and functional testing.
 Regression test scripts: - Test scripts that are a part of the regression test
suite.
 Re-usable functions/tasks :-Functions/tasks that are reusable across the
multiple applications and modules
 Repeatable steps:-Repeatable steps, to be performed during the manual test
execution.
 Data driven testing :- Manual test scripts that involves the data driven testing
using positive and negative set of data
 Complex test steps:-Test scripts involving tedious and complex steps. E.g.
Opening and verifying an application or url.
 GUI verification: - Test scripts involving GUI object properties verification.

Test Automation Guidelines and QTP Best Practices Page 9 of 25 10/14/2008

  Existence/property verification:-Test scripts that involve verification of the
existence or properties of the object, text, page, image or database.
 Automation feasibility :- Test scripts which can/cannot be automated ,should
be known prior to classifying the same as a good candidate for automation

.III General Guidelines

1) Automation scripts should only be written once the requirements for the
application under testing (AUT) are finalized and the manual team has been
engaged to write test cases and manual test scripts.

2) Test cases should be written with automation in mind. If a test case cannot be
wholly automated, then it should be split into two or more test cases, at least
one of which can be fully automated, and at least one of which will be executed
entirely manually.
If the Manual team delivers a test case that cannot be fully automated to the
Automation team, the Automation team should request that the manual team
split the test case.
This is done to simplify coverage reporting – it can always be assumed that an
automated test covers the full scope of the corresponding test case without
exceptions.

3) Automation scripts should be created on a test case-by-test case basis.

Automations should be created only where positive ROI is anticipated, based on
the requirements defined in the test case.

4) Use Common Libraries for activities like Reporting, Database Access etc.

5) Use Exit conditions and Exception Handling wherever applicable.

.IVQuick Test Pro

Purpose

Mercury’s Quick Test Pro will be used for Test automation by the SDRUP QA team. This
document lays down the Standards, Naming Conventions and Best Practices to be used
preparing automated test scripts using Quick Test Pro.

Audience

This document is for any automation engineer following the SDRUP QA process and
using Mercury’s Quick Test Pro. This is also for any member of the project or
development teams interested in understanding how testing team develops the
automated scripts using QTP.

Summary

Test Automation Guidelines and QTP Best Practices Page 10 of 25 10/14/2008

Quick Test Pro is a Test Automation Tool that helps teams to automate the test cases,
and execute automated test run.
Mercury Quick Test Professional provides the industry’s best solution for functional test
and regression test automation - addressing every major software application and
environment. Quick Test Professional satisfies the needs of both technical and non-
technical users. It enables you to deploy higher-quality applications faster, cheaper, and
with less risk.
Quick Test Professional provides an interactive, visual environment for test
development.
Mercury Quick Test Professional allows even novice testers to be productive in
minutes. User can create a test script by simply pressing a Record button and using an
application to perform a typical business process. Each step in the business process is
automated documented with a plain-English sentence and screen shot.

.V QTP Specific Best Practices

The below section specifies the QT Pro specific best practices to be used by the testing
team for developing test scripts.

Function libraries - Develop the reusable functions using the compile modules.

1. Custom Log File

Under certain erroneous conditions QT Pro aborts abnormally, closing the test result
file created. Under such circumstances the results of the test run are also lost. To
handle this, a custom log file will be created to log the test results of the
automation test run.

2. Name of the Custom Log File

The name of the log file created will include the name of the test run and the date
of the execution of the test. Thus the unique custom log file will be created for each
test run.

3. Checkpoints
A Checkpoint is typically created at a point in the script where the state of an object
can be confirmed across builds. QT Pro supports several different types of
checkpoints. The checkpoint captures object information and stores in an expected
folder. During playback, the object information is recaptured and stored in the
result folder and compared with the baseline to validate whether the checkpoint
passes or fails. QT Pro supports a range of checkpoints of which the following were
deemed suitable for the automated testing exercise:

 Standard Checkpoint: This captures and compares the properties of standard

objects, window in the application. This can support the validation of windows
and objects used in the application. It also provides specialized support for
environment-specific objects such as Java objects, Visual Basic Data controls,
ActiveX controls, HTML and Power Builder data windows, and Oracle Forms
base-table blocks.
 Text area check point
 Text checkpoint – This check point can be used to read texts and verify the
contents on gui objects and bitmaps.
Test Automation Guidelines and QTP Best Practices Page 11 of 25 10/14/2008
  Image Checkpoint
 Bitmap Checkpoint
 Table Checkpoint
 Page Checkpoint
 Data base checkpoint – Database checkpoint verifies the data contents in the
database.

4. Synchronization points
Synchronization points are used to ensure that QT Pro does not try to execute the
next statement within the script before the application is ready to accept the next
command. Browser “name”.page “name”.sync statement is used for
synchronization. The options that can be used to synchronize the test are as follows

 Wait Property –The synchronization point instructs Quick Test to pause the
test until an object property achieves the value that has been specified. When a
synchronization point is inserted in to the test, Quick test pro generates a Wait
Property statement in the Expert View.

 Exist or wait – One can insert Exist’ or ‘Wait’ statements that instruct Quick
Test to wait until an object exists or to wait for a specified amount of time
before continuing the test.

 One can also increase the default timeout settings in the Test Settings and
Options dialog boxes in order to instruct QuickTest to allow more time for
certain events to occur.

5. Smart Identification
During a test run, if the script fails to recognize an object using the mandatory
properties of that object, it makes use of the assistive properties, which could
recognize that particular object.

6. Shared Object Repository

QTP can create and utilize the same object repository file for any number of test
scripts which helps in saving a huge amount of disk space and also helps in
maintaining consistency if any property of an object is updated.

7. Capturing of Active screen

This helps in locating the actual object on the screen during any point in the test
run.

8. Call to Win runner test scripts

Call to other win runner test scripts can be made in the QTP script, thus saving the
previous effort made if any.
9. Comment the code in the script wherever required.
10.Exception Handling
Do Exception Handling in the script. Exception handling is done in QTP using
Exception editor in QTP.

12. Debug the script

Debug the scripts to verify smooth and authentic functioning of the scripts and run
one complete cycle of test execution before code freeze.
Test Automation Guidelines and QTP Best Practices Page 12 of 25 10/14/2008
13. Create a test script file to call all the test scripts in a specified series in the batch
mode.

14. Run the Test suite in a batch mode.

15. Maintain the various versions of the test scripts using the version control system.

16. New Environment Support: Supports Web services, .NET 2.0, Fire fox 1.5,
Netscape 8, Macromedia Flex 2, Win XP 64 bit, Internet Explorer 7, and the latest
ERP/CRM applications

17. Open XML Report Format for Test Results: Stores test results in an open XML
format, enabling you to easily customize the reports according to your own
requirements, and to integrate the test result information with other
applications. Test results can now be exported to HTML

.VIScript Organization
This section specifies the various standards to be followed by the SDRUP QA team while
developing, maintaining and organization of the QT Pro scripts

.A Coding Standards

This section specifies the various standards to be followed by the SDRUP QA team while
developing and maintaining the QT Pro scripts.

Goals of these standards -

This section explains the goal of having the coding standards to be used in the
development of test scripts. Following are two basic, but very important goals:

• The use of these guidelines and standards should result in readable code and
should encourage adherence.

• The resulting documentation should be easy to maintain.

Before having the QT Pro code, one should have a process for writing the code.
Thus this section will help the Automation Team to use these standards while
developing the code and maintaining the QT Pro scripts.
Some amount of standardization is especially important in large development
organization such NBC Universal, for writing the programs or scripts. The code
will be shared amongst the development and UAT team and will also be used
and maintained by the SDRUP QA team. Thus it must be clear what the code
does, how it should be used, how it can be extended, etc. The standards within
this section have been written to balance the group need for standardization
with the individual's desires to code in the ways they feel most efficient.

Test Automation Guidelines and QTP Best Practices Page 13 of 25 10/14/2008

 Scope and application of the standards.
This section is divided into two areas -- Rules and Guidelines.

Rules are those coding standards that are "necessary and required" coding
practices that have to be followed by the Test Automation engineer. Everyone is
expected to follow these "rules".

Guidelines are "suggested" coding practices that have been written to

recognize the need for individuality and for common coding practices. The
purpose of the guidelines is to provide a framework upon which we can all
create better code. However, the guidelines are not meant to impede
engineering efforts when these guidelines are found to be in direct conflict with
an individual's preference, so long as that preference is implemented
consistently and is well documented. Finally, because it has been recognize that
this opens the code upon to individual stylist coding habits, it is important that
these habits are well documented and will then become the basis for all other
updates within the affected files.

Documenting code

The documentation section is a block of comments for a particular test script, and
describes the objectives, flow and dependencies of the script.
The documentation section is required for every script and file. Lack of a
documentation block will be severely detrimental to readability and maintainability of
the script.

The code in the test script should be well commented. The test engineer should
include the following in the test script.
 Any updates made in the script should be documented in the form of the
comments. The part of code, which has been changed or added to the script, should
be commented so that the author or other test engineers can easily locate any
change in the script. Date of change, any cross-reference to the Change Control
Form / requisition number and the description of the change and the reason for
change has to be included in comments.
 Purpose of using a function, checkpoint, and external file should be specified using
the comments.
 On the beginning on every Test script the associated Test script in the Quality
Center should be mentioned.

Layout of QTP Script Files

The layout for a class will be broken up into the following main sections:

Test Automation Guidelines and QTP Best Practices Page 14 of 25 10/14/2008

 Action Header
The Header in each Script File will contain the following information

/*=======================================================
= */
*Action Name - Name of the Action. The action name will specify the module name
*
* and type of test action
* *Action Type – Specify the type of action e.g. Functional
*
*Module Tested – Name of the module to be tested
*
*Object Repository – Name of the Object Repository
*
*Libraries Used – Name of Library files (if used)
*
*Called From – Name of the calling action
*
*Created by – Name of the test engineer
*
*Date – Date of creation of the Test Action
*
*Updated- Name of the test engineer who updated the script with date
*
*=======================================================
= *

 Action Code

• Test Action #
• Corresponding VB script Code

Guidelines
Line Spaces
Line width should not ordinarily exceed 80 characters. Use your best judgment.
IF / Else Statement

Place the IF keyword and conditional expression on the same line.

E.g.
if (expression)
{
statement ;
}
Test Automation Guidelines and QTP Best Practices Page 15 of 25 10/14/2008
 else
{
statement;
}
or
if(expression) {
statement ;
} else {
statement;
}
While

The WHILE construct uses the same layout format as the IF construct.
The WHILE keyword should appear on its own line, immediately followed
by the conditional expression. The statement block is placed on the next
line. The curly braces may optionally be indented by up to 1 tab space.

Examples
while (expression)
{
statement;
}
or
while(expression) {
statement;
}
Do..While

The DO..WHILE form of the while construct should appear as

shown below:

Examples

do
{
statement;
} while (expression);

or

do {
statement;
} while (expression);
Switch

The SWITCH construct uses the same layout format as the if construct.
The SWITCH keyword should appear on its own line, immediately
followed by its test expression. The statement block is placed on the next
line. The curly braces may optionally be indented by up to 1 tab space.

examples:
switch (expression)
Test Automation Guidelines and QTP Best Practices Page 16 of 25 10/14/2008
 {
case n:
statement;
break;
case x:
statement;
// Continue to default case
default:
statement;
break;
}

or

switch (expression) {
case n:
statement;
break;
case x:
statement;
// Continue to default case
default:
statement;
break;
}

Test Script Template

The test script template will specify the template to be used by the
testing team for writing the test scripts. Below is the list of various types
of files to be created in the development of the test suite and the
template to be used for each type of file.

Startup file
 Single startup file to load the application
 Load function libraries
 Make the mappings of the custom objects to standard objects
permanent.

Shell Script File

 Open connection to the test data set (ODBC /Excel)
 Call script files
 Close connection to the test data set

Object Repository File:- A file with the extension *.tsr. This file contains
the information about the objects used in the test.
Script file

 Separate action for each module

 Separate action file will be created, depending upon the type of testing
performed (e.g. functionality, database)
 Script header is to be included in all the action files.
Test Automation Guidelines and QTP Best Practices Page 17 of 25 10/14/2008
  Manual test case name, for which a code is being written, is to be
mentioned.
 Comments to be included.
 Purpose of using a function in the script, is to be specified in the
comments.
 Preferably small action files with modular approach.

.B Naming Conventions

Following are the naming conventions and standards to be followed by the automation
team in the interest of script readability and maintainability.

Variables (Based on Scope)

Scope Prefix Followed by

Global g_ Variable type prefix

Notes: Local Variables do not require a scope prefix.

Variables (Based on Variable type)

Variable Type Prefix Followed by

String s Variable name beginning with upper case for each
segment of the name
Integer i Variable name beginning with upper case for each
segment of the name
Boolean b Variable name beginning with upper case for each
segment of the name
Float f Variable name beginning with upper case for each
segment of the name
Variant v Variable name beginning with upper case for each
segment of the name

Constants

All constants should be Upper case.

Example:

1. For variable “Sales Invoice” which is a string and global the naming should be
g_sSalesInvoice

2. For variable “Invoice Number” which is an integer and local the naming should be
iInvoiceNumber

3. For constant “File Type” the naming should be FILETYPE

Functions

Test Automation Guidelines and QTP Best Practices Page 18 of 25 10/14/2008

Functions should be created for repeating steps or activities. Identify Function
Candidates before creating Scripts.

Function Type Prefix Followed by

GUI related bsr Object name beginning with upper case for each segment
of the name
Checkpoint related pge Object name beginning with upper case for each segment
of the name
Generic win Object name beginning with upper case for each segment
of the name
Database Access txt Object name beginning with upper case for each segment
of the name

The function should be named in the following pattern.

<Function Type>_<Module Name>_<Function Name>

Example:

To name a function for Login in Sales Management module, the naming should be
gen_SM_Login

.1 Function Documentation

For VBS functions, the documentation block should be written as follows.

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
' Description: Login to Mercury Tours
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
' Parameters:
' sURL - URL
' sUserName - User Name
' sPassword – Password
‘ Return Value: Status of Login (PASS/FAIL)
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~

.2 Function Parameters
The function Parameters should follow the same naming convention specified
above.

.3 Return Values
If a function doesn’t return any value create a Sub Procedure instead of a Function.

Test Automation Guidelines and QTP Best Practices Page 19 of 25 10/14/2008

Objects

Variable Type Prefix Followed by

Browser bsr Object name beginning with upper case for each segment
of the name
Page pge Object name beginning with upper case for each segment
of the name
Window win Object name beginning with upper case for each segment
of the name
Text Box txt Object name beginning with upper case for each segment
of the name
Label lbl Object name beginning with upper case for each segment
of the name
Combo Box cbo Object name beginning with upper case for each segment
of the name
Check Box chk Object name beginning with upper case for each segment
of the name
Radio Button rad Object name beginning with upper case for each segment
of the name
Button btn Object name beginning with upper case for each segment
of the name
Image img Object name beginning with upper case for each segment
of the name
Link lnk Object name beginning with upper case for each segment
of the name
Frame frm Object name beginning with upper case for each segment
of the name
Dialog dlg Object name beginning with upper case for each segment
of the name

Example: For Userid Text Box, the naming should be txtUserID.

.C Implementation

.1 Implementation section structure

Scripts should generally be divided into three blocks to ensure readability and
maintainability:

.a Initialization block
All resources/environment variables should be loaded in this block

Test Automation Guidelines and QTP Best Practices Page 20 of 25 10/14/2008

 Example:

' Create Objects

ExecuteFile "..\..\Keyword\Common\Objects\lib_Object.vbs"
rc = gen_CreateObjects("..\..\Mercury\Common\Data\dt_Object.xls")

.b Execution block

Example:

‘ Login to Mercury Tours and Find a Flight

rc = gen_Mercury_Login(“mercury”,”mercury”)
rc = gen_Mercury_FindFlight(“roundtrip”,”New York”,”Paris”,”Business”)

.c Cleanup block
This block should close open files and unload resources and cleanup Browsers
etc.

Example:

‘ Close the Browser

rc = Browser_Close(bsrWelcome)

.2 Pathnames

Always use relative path instead of absolute path.

Example:

Instead of using “c:\qtp\mercury\common\dt_Obj.xls” use a path with reference to

the script like “..\..\common\dt_Obj.xls”

.VIIFunction Libraries
The Functions libraries should be divided into two types. Common and Module specific.
Following naming convention should be used for Library Files

Common Libraries:
lib_<Common Library Type>

Example:
For Database related function library name it as lib_Database
For Reporting related function library name it as lib_Report

Module Specific Libraries:

lib_<Module Abbreviation>_<Gen/Chk>

Example:

Test Automation Guidelines and QTP Best Practices Page 21 of 25 10/14/2008

For Generic Function Library related to Sales Management Module name it as
lib_SM_Gen
For Checkpoint Function Library related to Sales Management Module name it as
lib_SM_Chk

Test Automation Guidelines and QTP Best Practices Page 22 of 25 10/14/2008

.VIIIDirectory Structure
Test Automation should follow a Directory Structure within Quality Center for common
files used across modules.

Example:

Automation – Automation Folder

QTP – Tool used
Common – Common files
Objects – Object Repository
Obj1.tsr
Obj2.tsr
Data – Data related to the Tests
dt_SM
dt_AM
dt_CS
Libraries – vbs Library Files
lib_Report
lib_SM_Gen
lib_SM_Chk

See section IX: Version Control for a discussion of the directory structure to be used
while scripts are under development and stored in ClearCase.

.IXVersion Control
Rational ClearCase will be used for Version Control of Automation Scripts during
development. Validated Scripts will be uploaded to Quality Center.

The ClearCase directory structure should be created to conform with the directory
structure created by the manual testing team for the corresponding project in Quality
Center. This will ensure that the automation scripts may be developed and stored in
ClearCase and then easily migrated to Quality Center when completed.

.A Check In/Check Out

When Checking In/Checking Out automation scripts, the ClearCase activity name must
be properly set. The activity name will be used for tracking scripts based on version of
the AUT.

Example :

If automation team develops following 3 scripts for version 1.0 of AUT then they will be
checked in with Activity Name as “AUT 1.0.”

AUT 1.0 ---- ScriptA (1.0)

ScriptB (1.0)
Test Automation Guidelines and QTP Best Practices Page 23 of 25 10/14/2008
 ScriptC (1.0)

If the AUT version changes to 2.0, and ScriptA needs to be modified without any
changes in ScriptB and ScriptC, Check Out all the scripts using Activity name “AUT 1.0.”
Modify ScriptA and Check In all the Scripts using another Activity name reflecting the
updated version of the AUT, i.e. “AUT 2.0.”

AUT 2.0 ---- ScriptA (1.1)

ScriptB (1.0)
ScriptC (1.0)

.X Defect Tracking

.A Defect Logging & Tracking

All the defects will be tracked in ClearQuest.

There will be a dedicated ClearQuest project for each automation effort. For example,
there is a ClearQuest project called "FATS" and another ClearQuest project called "FATS
Automation." Automation defects should be tracked in the “FATS Automation” project,
not in the regular "FATS" project, and vice-versa.

When applying bug fixes to an automation that has been copied to Quality Center,
these bug fixes should be applied to the scripts in ClearCase and re-tested before being
copied to Quality Center. Automation scripts should be copied to Quality Center only
when they are believed to be bug-free and ready for execution.

.B Defect Flow Overview

Below is the defect state flow currently used in Clear Quest:

Test Automation Guidelines and QTP Best Practices Page 24 of 25 10/14/2008

 Opened
Failed

Return to
Analysis
Return to Test
Dev Move to Failed Reopen
Test
Passed

Design Move to
Submit Analyze Schedule Completed Test Test Close
Passed Closed
Opened Analysis Design Development Test

Withdraw Return to
Reopen Design

Hold Hold
Hold Design Development
Analysis
Reopen
Withdrawn

On Hold Opened

Close
Development

Dev
Completed

Test Automation Guidelines and QTP Best Practices Page 25 of 25 10/14/2008