Coding conventions are suggestions designed to help write code using Microsoft Visual Basic Scripting for QTP. The document describes the coding standards to be followed while developing automated test scripts for Oracle applications. In general, this document talks about a general purpose set of coding conventions that will define minimum requirements while coding using QTP.
1.1 Background
1.2 Objectives
The following are the main objectives of this document
Define guidelines for test script development.
Define naming conventions for test scripts, data sheets, library files, reusable actions and Result files.
Outline Best practices
1.3 Purpose
A standardized process for automated test script development is important due to the following reasons
Automated regression test scripts are developed with a long term perspective. The test scripts thus developed should be highly maintainable. Also, hardly automated test scripts are maintained for its whole life by the original author.
Scripting conventions improve the readability of the software, allowing engineers to understand new scripts more quickly and thoroughly.
Improve readability by ensuring a “common look and feel” to the scripts regardless of how many people have worked on it.
Using consistent Scripting standards and naming conventions will not only contribute significant time and resource savings for both the initial construction and long term maintenance of automated test scripts, but also improve script efficiency dramatically. Developing these standards prior to construction and adhering to them during construction is thus very important.
2 Naming Conventions
Good coding conventions result in precise, readable, and unambiguous source code that is consistent with other language conventions and is as intuitive as possible. The coding standard guideline is to standardize the way coding is done across the automation effort for Oracle applications.
2.1 Constant Naming Conventions
Earlier versions of VBScript had no mechanism for creating user-defined constants. Constants, if used, were implemented as variables and distinguished from other variables using all uppercase characters. Multiple words were separated using the underscore (_) character.
Example:
INVENTORY_ORG = “STOR”
While this is still an acceptable way to identify your constants, you can create true constants using the Const Statement. This convention uses a mixed-case format in which constant names have a “con” prefix. One declaration per line is recommended since it encourages commenting
Example:
Const conInventoryOrg = “STOR”
2.2 Variable Naming Conventions:
A simplified form of Hungarian notation should be used to indicate the data type and the scope of a variable.
Use a lower case prefix for the type
Concatenate scope and type prefixes, in that order, add an “a” for Action level variable Ex: aintQuantity (where “a” indicates that the variable is at action level)
To enhance readability and consistency, use the following prefixes with descriptive names for variables in your VBScript code:
Subtype Prefix Example
Boolean bln blnFound
Byte byt bytRasterData
Date (Time) dtm dtmStart
Double dbl dblTolerance
Error err errOrderNumber
Integer int intQuantity
Long lng lngTotalPrice
Object obj objCurrent
Single Sng sngAverage
String Str strFirstName
2.3 User Defined Functions
The function or procedure name should be descriptive of its primary purpose.
Example:
Sub RunConcurrentProgram (. . .)
In VBScript, there are two kinds of procedures; the Sub procedure and the Function procedure. A Function in the script must always be used on the right side of a variable assignment or in an expression.
Example:
StrStatusMessge = GetStatusbarMessage ()
2.4 Parameters Naming Conventions:
When parameters are created give the parameter-column name as the name of the field in the Oracle form. Because using the field-name, it will be clear what Oracle field is parameterized when maintenance is required. A prefix of “P_” will be added to the Parameter thus defined.
Example:
P_Number
2.5 Object Naming Conventions:
During test script development when there is a requirement to use descriptive programming for object identification. Therefore it is necessary to use some recommended conventions to name the objects. Suffix the object type with the name of the object. The following list some of the objects in oracle forms and the required prefix to be followed. The name of the Object will be designated based on the Form Name as designed in the Oracle Applications in Initial Capital format. So for example a form with the name “Find Orders” in Oracle will be given the name “FindOrders” for the purpose of descriptive programming.
Object Type Suffix Example
Window Window/Form SubmitRequestWindow or SubmitRequestForm
Button Button ApproveButton
Tabbed Region Tab MainTab
Check Box CheckBox GlobalCheckBox
In Oracle Forms objects are recognized as a Parent-Child hierarchy. For example under the Sales Order Window there will be Tab Regions which in turn will have editable text fields. For this purpose the description of the Child object must be preceded by its corresponding Parent’s name as well.
So for example, if the Oracle Form is named “Sales Order Form” in which there is a tab region named “Main” and under which there is a text field called Customer Number then the object description should follow the hierarchy as below:-
Sales Order Form description: - SalesOrderWindow
Main Tab Region’s description: - SalesOrderWindow_MainTab
Text Field’s description: - SalesOrderWindow_MainTab_CustomerNumberTextField
2.6 Code Commenting Conventions:
The following are the commenting conventions to be used while script development.
All procedures should begin with a brief comment describing what they do. This description should not describe the implementation details (how it does it) because these often change over time, resulting in unnecessary comment maintenance work, or worse, erroneous comments.
Arguments passed to a procedure should be described when their purpose is not obvious and when the procedure expects the arguments to be in a specific range.
Return values for functions and variables that are changed by a procedure, especially through reference arguments, should also be described at the beginning of each procedure.
Every important variable declaration should include an inline comment describing the use of the variable being declared
Variables, controls, and procedures should be named clearly to ensure that inline comments are only needed for complex implementation details.
At the beginning of the script, there should be an overview that describes the script, enumerating objects, procedures, algorithms, dialog boxes, and other system dependencies. Sometimes a piece of pseudo code describing the algorithm can be helpful.
There should be header comments included for procedures. The header comments should include the following section headings:
2.7 Checkpoints and Description of Checkpoints
When a Checkpoint is inserted, add a comment which details the type check point, objective of the checkpoint, the value / object /event checked.
3 Test Script/Components Header
Header information are comments usually at the beginning of a test script, reusable action, user defined function or procedure, library files or object definitions.
All procedures and functions should begin with a Header block describing the functional characteristics of the routine (what it does). This description should not describe the implementation details (how it does it), because these may change over time, resulting in unnecessary comment maintenance work or, worse, erroneous comments.
3.1 Procedures/Function headers
‘*********************************************************
'* Function Name : Name of the function
'* Process Thread : NA.
'* Object/Details : A brief description of the flow of the function
'* Input Parameters : Input variables description to the function
'* Output Parameters : Output variables description to the function
'* Pre-Conditions : Any pre-requisites for the function
'* Post-Conditions : NA
'* Reusable Actions/Functions Used: None.
'* Author : The name of the person who created the function
'* Date : The date on which the function was created
'* Comments : Comments if any
‘*********************************************************
3.2 Reusable Action Header
Reusable actions should contain the following header information.
‘*********************************************************
'* Objective : The main objective of the reusable action
'* Action input : input action parameters
'* Action output : output action parameters
'* Pre - Conditions: The preconditions that should be satisfied before the
Action can be called
'* Post - Conditions: Post conditions that should be executed, if any
‘* Author : The name of person who originally created
‘* Date : The date on which the action was created
‘* Last Modified date: The last modification date
‘*********************************************************
3.3 Library File
‘*********************************************************
'* Name : Name of the lib file
'* Functions : Name and description of the functions in the file
'* Classification : General or oracle module name.
‘*********************************************************
3.4 Object Definition File
‘*********************************************************
'* Name : Name of the objects file
'* Classification : Common or Oracle module name
‘*********************************************************
3.5 Test Script
‘*********************************************************
'* Project Name : Name of the Project
'* Test Reference : Test Case name related to the script
'* Script Title : Name of the automation script
'* Test Version : Script version
'* Test Version Date: Version Date
'* Application Code Version: Application Version
'* Created by : Name of the person who created the script
'* Date of script Creation: Creation date of the script
'* Purpose/Description : A brief description of the script
'* Input Excel Sheet Name: Input Data Sheet Name of the script
'* Results Excel Sheet Name: Result Sheet Name for the script
'* Initial Conditions: Any initial setups that may need to be performed before running the script
'* Dependencies/Assumptions: Describe if there are any dependencies for the script
'* Pass/Fail Criteria: List out the PASS/FAIL conditions for the script 1. Successful Generation of Invoice
‘****************************************************************
4 Script and Components Naming
4.1 Test Script Naming
Test Script names should prefix with Application Name followed by an underscore and the word “SCN” and in succession followed by a short description of the script.
Try to keep your test script names simple and descriptive
Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form.) in Initial Capital format
The Script Name should contain a reference to the test case or test suite
Use the underscore “_”for separation.
Example:
ApplicationName_”SCN-”ScriptName
4.2 Action Naming
Actions created using QTP should have a meaningful Name.
They should be in mixed case with the first letter of each word capitalized and prefixed by the letters “RU” and an underscore.
Example:
RU_Login should be the name assigned for the reusable action designed for logging into the Oracle Front End application.
4.3 Library File Naming
A library file would be created as a place holder for a group of general user defined functions. Also there would be a library file specific to each module. The name of the library file should start with the application name and a meaningful name/module name. Use “_” as a separation character. When the module name/general name has multiple words, they should be in mixed case with the first letter of each word capitalized
Example:
ConcurrentProgram.vbs
4.4 Data File Naming
Input data files would be maintained separately. The data files are excel spread sheets that would be called inside the test dynamically by the script during execution. Each test script will have an input data file. The data file names should be same as the test script except that they will be followed by the string “Data”. This would help in associating a data file with a test script and the test case.
Example:
“ScriptName”Data.xls
4.5 Object File Naming
The object file will be designed based on the responsibility in the Oracle Applications and the whole file should have the object descriptions of the different Oracle Forms that are available under that responsibility. The Object file must be named accordingly as the requisite responsibility name followed by the word “Objects” preceded by an underscore.
Example:
“ResponsibiltyName”_Objects.vbs
Test Script Usage and Maintenance
A Test script usage & maintenance document should be prepared for each script or for a group of test sets. The document helps in future maintenance of scripts and for easy execution of scripts by anyone. The document should address the following:
Scope of test script or test set
Execution steps for the scripts
Opening the test through QTP
Reference to Test plan & Test cases
Viewing/Editing test data
Executing the test script
Viewing/Analyzing Results & log
Baseline data used for script execution
Test scripts location
Limitation of test scripts
Reference – PEs, BRDs, SRDs etc..
