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
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
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
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
When …..
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.
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
Some of the key activities that we perform as part of test automation are
listed below:
Adhere to the above-mentioned steps to ensure a test suite that has the
following features
The following points should be considered while identifying the good candidates for
automation
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.
4) Use Common Libraries for activities like Reporting, Database Access etc.
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
Function libraries - Develop the reusable functions using the compile modules.
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:
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.
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.
• The use of these guidelines and standards should result in readable code and
should encourage adherence.
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".
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.
The layout for a class will be broken up into the following main sections:
/*=======================================================
= */
*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
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
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;
}
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.
Object Repository File:- A file with the extension *.tsr. This file contains
the information about the objects used in the test.
Script file
.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.
Constants
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
Example:
To name a function for Login in Sales Management module, the naming should be
gen_SM_Login
.1 Function Documentation
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
' 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.
.C Implementation
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
ExecuteFile "..\..\Keyword\Common\Objects\lib_Object.vbs"
rc = gen_CreateObjects("..\..\Mercury\Common\Data\dt_Object.xls")
.b Execution block
Example:
.c Cleanup block
This block should close open files and unload resources and cleanup Browsers
etc.
Example:
.2 Pathnames
Example:
.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
Example:
Example:
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.
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.”
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.”
.X Defect Tracking
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.
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