WinRunner Coding Standard (WRCS)

Table of Contents

1. Introduction....................................................................................................................................... 2

1.1. Purpose...................................................................................................................................... 2
1.2. Intended Audience..................................................................................................................... 2

2. Naming Convention........................................................................................................................... 3

2.1 Variable naming...................................................................................................................... 3

2.2 Function Naming..................................................................................................................... 3
2.3 Test Script Naming................................................................................................................. 3

3. Header.............................................................................................................................................. 3

3.3. Start of script.............................................................................................................................. 3

3.4. Step conventions........................................................................................................................ 3
3.5. Start and End of the script.......................................................................................................... 3
3.6. Setup and teardown scripts........................................................................................................ 3
3.7. Start of Compile Module............................................................................................................. 3
3.8. Start of Function......................................................................................................................... 3

4. Comments......................................................................................................................................... 3

4.1. Comments Usage Conventions.................................................................................................. 3

5. Indentation........................................................................................................................................ 3

6. General guidelines............................................................................................................................ 3

Page 1 of 9
 WinRunner Coding Standard (WRCS)

1. Introduction
Any good automation code needs guidelines or coding standards to be followed to be readable,
presentable and at the same time ensure it is executable. The coding standard brings in the good
rules being followed across projects into the project and hence value adds to the project. It also
decreases the maintenance cost, as it is well documented and readable.

1.1. Purpose
This document details the coding standards for Win runner scripting that will make the code
presentable and readable.

1.2. Intended Audience

 Project automation testing team
 Automation enthusiasts

Page 2 of 9
 WinRunner Coding Standard (WRCS)

2. Naming Convention
The first letter or letters of the variable name will indicate data type of variable. Second letter will be in
uppercase for the name (if the string name is composed of two words then recommended to use
Capital letter for each word). Use of the "_" underscore character should be avoided.

2.1. Variable naming

There should not be any separate naming convention for “Return Type” because it will not reflect
which type of data we are returning through this variable.

Sr.
Data type Example
No.
1. Strings strVariableName
2. Number nName
3. Boolean bName
4. Any return value rcValue
5. Flag flgStepNo

Further on Naming Conventions

Variable naming conventions should adhere closely to the established convention in most
programming language.

Variable Type Prefix Example

Window Win winName
Variant Var varRunType
Array Arr arrRefl
Date or Time Dtm dtmStarted
Query Qry qryEmployees
Boolean Bln blnEmplStatus / bName
Error Err errLimitBonus
Integer Int intCount / nName
Constants Con conName
Strings Str strVariableName
Any return value Rc rcValue
Flag Flg flgStepNo
Variable declarations

 All global variables should be declared at the top of the script immediately following the script
header.
 Parameters passed to or from (in or out or in/out) should immediately follow global variables.
 Local variables can be declared at the time of use.
 All variables must have descriptive comments added on the same line the variable is
declared.

Page 3 of 9
 WinRunner Coding Standard (WRCS)

2.2. Function Naming

 Function name can start with prefix (fn). First letter should be capital. Name should be
meaningful i.e. it should describe what the function is all about.
 Even if no prefix (fn) is attached with the function, there is no harm because the two small
braces always recognize functions uniquely.

For Example:
getValue() or fnGetValue()

Function parameters and Called Test parameters

 All parameters passed to or returned from a function must be declared and commented –
please see rules for global variables and local variables in section of variable declaration.
 It should appear immediately below the script header and after the variable declarations.

The declaration should include the type of the parameter (in or out or in/out).

Operator Usage Conventions

Operators should be preceded and followed by a space, for example:

If(empBonusIn <> empBonusOut)…

2.3. Test Script Naming

All scripts and Gui maps should have name, which are reflective of what they contain or based on
functionality within module. Like Tests related to web site registration might be called register or
register.gui.

For Example:
Tests related to web site registration might be called register or register.gui.

3. Header
3.1. Start of script
- To be more precise, incase of “Test Cases Covered”, we should have the “Test Case ID” which
is mentioned is our test case document.
- Instead of having log of all the “History”, we can have the “Creation Date”, “Last Modified Date”
and may be “Name of the person, if required, with these columns.
- Either ---- or ### can be used to mark the start or end of script

Page 4 of 9
 WinRunner Coding Standard (WRCS)

Example of Script Layout or structure

#_______________________________________________________________________________________________
# Project name - Mighty Joe
# Module - Login
# Script name - Login to Application
# Test case covered - Initial Gui Checks / Error Msgs Validation / Functional / etc
# Data files - none
# Dependencies - none
# Description - This script details scripts for initial GUI checks for the Login window
# Pre-conditions - Desktop (Before invoking application) No application window exist
# Post-conditions - No application window exist
# Global Variables used (if called script) -
# Functions Used, if calling script - none
# Revision history----------------------------------------------------
# Author - Tester Name Date - DD/MM/YYYY Ver -Draft
# Reviewed By - TL Date - DD/MM/YYYY Ver -1.0.0
# Reworked By - Tester Name Date - DD/MM/YYYY Ver -1.0.0
# Reviewed By - TL Date - DD/MM/YYYY Ver- 1.0.1

# Review Sheet - Name of Review Sheet

#_________________________________________________________________________

#_____________________________Start of Script_________________________________

# Declaring Global variables

--------------------Code Here-----------------------------

# Parameters Passed

--------------------Code Here-----------------------------

# Test Case 1 - Login to Application with Admin rights – Start

--------------------Code Here-----------------------------
# Test Case 1 - Login to Application with Admin rights - End

# Test Case 2 - Login to Application with superuser rights – Start

--------------------Code Here-----------------------------
# Test Case 2 - Login to Application with superuser rights – End

#_____________________________End of Script_______________________________

Page 5 of 9
 WinRunner Coding Standard (WRCS)

3.2. Step conventions

Start of Test Step

“Test Case ID” is more suitable instead of “Test Cases Covered”, if test case ids are used

For Example:
###########################################################
### Test Case Id:
### Test Step:
### Expected result:
###########################################################

Pass/fail routine

#-------------- Pass TestStep routine ------------

tl_step(Step No,0,ExpectedResult/Remarks");

#-------------- Fail TestStep routine ------------

tl_step(Step No,1,ExpectedResult/Remarks");

End of Test Step

###########################################################
#------------ End of Test Step
###########################################################

3.3. Start and End of the script

Use the following to indicate the start and end of script

###########################################################
#-------------Start of the Script
###########################################################

# code comes here

###########################################################
#-------------End of the Script 1.0
###########################################################

Page 6 of 9
 WinRunner Coding Standard (WRCS)

3.4. Setup and teardown scripts

Each function/ test case has certain preconditions that are needed. The setup script can perform the
necessary setup and teardown function will clear the preconditions so application returns to base
state. The startup and teardown scripts are called scripts and follow the conventions of the called
scripts

3.5. Start of Compile Module

“Creation Date” & “Last Modified Date” will be more suitable than the Revisions because it does not
tell much about the person working on that project/script and even his replacement will not be
exposed to others

For Example:
########################################################
### Module Name:
### Description:
### Revisions :
### No. Date Developer Addition/Change
### 2 09/11/07 Rahul
### 1 09/11/07 Ashish
#########################################################

3.6. Start of Function

Function Header can be of this format
#########################################################
### Function Name:
### Description:
### Parameters:
### Return value:
### Revisions:
### No. Date Developer Addition/Change
### 2 09/11/07 Vijay
### 1 09/11/07 Abhra
#########################################################

#########################################################
### Function: <Function Name> CopyFile()
### Description: <What this function does>
### Input Parameters:<Type of parameter it takes>
### Returns <Return Value>
### Usage: <How to use the function in the scripts>

Page 7 of 9
 WinRunner Coding Standard (WRCS)

### iStatus = CopyFile()

### Author: Cybage Software Pvt. Ltd.
#########################################################

Note: Its Better to have Company’s Name in “Author” section instead of person’s Name.

4. Comments
4.1. Comments Usage Conventions
Adding comments to a script is recommended. Comments are important elements in a script.
Good and consistent commenting practices facilitate an understanding of what the script and its
functional sections do in conjunction with the script header. Make sure that comments explain the
code and not just a cut paste or earlier comments.

Comment starts with #. There should be proper comments in the scripts. Comments for each line
are not required. Instead, use comments for groups of closely related lines or whenever the code
is confusing or may be difficult to understand. For extensive explanations, an indented section
with a meaningful name (describing functionality for particular code) can be used.

For Example:
#-------Invoking application---------
fnStartPureCMS();

Script Section Comments

It is mandatory to add comments preceding sections of a test script. The comment should
describe the test scenario that is being performed.

Variable declaration comments

It is mandatory to add comments to all variable declarations. The comment should explain
what data gets assigned to the particular variable.

Array declaration comments

It is mandatory to add comments to all array declarations. The comment should explain what
data gets assigned to the particular array.

Conditional branching comments

It is mandatory to add comments to all conditions or conditional branching. The comment

should explain what condition is being checked. For example:

Page 8 of 9
 WinRunner Coding Standard (WRCS)

do # Parses through the table.

{
statement_1;
statement_2;
}
while(varCurrentRow <> varRowsCount); # Not the last row in the table

Called test and user-defined function comments

It is mandatory to add comments to all calls or call statements. The comment should explain
what the called test or function will do. For example:

call "ProjectSetupVariables" (); #Loads script containing all public variables

or
rc = login (); #Performs the login routine for the application based on user role

5. Indentation
Indentation should be used to clearly define and allow easy access to different sections of the scripts
and compile module. The test script includes places for functions, variables and user action in form of
scripts where as compile module includes user-defined function.

6. General guidelines

1. Hard-coded paths and machine names should be avoided in test scripts. This makes them very
difficult to move from one machine or environment to another. Instead all those will be kept into a
excel file and can be used in the scripts as variable.
2. Unnecessary user messages should be suppressed. – Delete or comment out all debug user
messages, trial code routines. This will ease the batch runs for scripts
3. While running the script synchronization problem may occur. The synchronization problem should
be covered with code only. i.e. the delay for window synchronization should not be set under
Settings-> General options. It should be done with the help of coding whenever needed.
4. The script should complete its run even though verification/check fails. Appropriate setting should
be done for it Setting->Run options of Win runner.
5. User load commands instead of reload whenever it is possible as reload places compiled function
libraries into memory.
6. Consider debugging scenarios while coding itself (Date, time stamps, Level of verbosity in the
result file, Level of Pausing etc.).

Page 9 of 9