Scripting Standards v6.0

Download Scripting Standards v6.0

Post on 25-Apr-2015




2 download

Embed Size (px)


CVS Caremark Automation QTP Scripting Standards Information TechnologyScript Design Specifications

Version 6.0 February 5, 2009

Document InformationProject Name Author(s) Contributor(s) First Issued On Version Number Last Updated File Path/Name History Date 12/26/07 01/07/08 01/09/08 02/01/08 02/05/08 03/22/08 1.0 2.0 3.0 4.0 5.0 6.0 Version Author Rohan Patnaik Rohan Patnaik Rohan Patnaik Dan Marek Dan Marek Rohan Patnaik Contributors NA Dan Marek , Vivek Bhanot Dan Marek , Vivek Bhanot Enterprise Regression Team Enterprise Regression Team Enterprise Regression Team Changes Initial Draft Added updated information for Naming Conventions , Data Retrieval Steps Added Script Design Section Added updates after review with the Enterprise Regression Team Added Error Handling Naming conventions Added Modular Automation Framework Design Details QTP AUTOMATION SCRIPTING STANDARDS Rohan Patnaik Dan Marek , Vivek Bhanot , Radha Rao , Vijay Nori , Chandra Vadamodula , Lakshmi Chadive , Chisore Nyirenda , Mark Esposito , Shama Narasimhan, Maria Vandermeersch 26 December 2007 6.0 03/22/2008

[Document Versioning Guidelines: Version 1.0 version submitted to Team for Sign-off Review Version 2.0 Updates after First Review with Team Signed-off Naming convention and Data Retrieval sections at the end of design Version 3.0 Added Script Design Section after review with the Team Version 4.0 Added updated steps after review with the Enterprise Regression Team including RxClaim and RECAP members Version 5.0 Added minor modifications as per the team recommendations Version 6.0 - Added Modular Automation Framework Design Details

QTP Scripting StandardsA consistent set of coding conventions is required to standardize the structure and coding style of all scripts. Using good coding conventions would result in clear, precise and readable source code that is consistent with other language conventions and is intuitive.

Naming ConventionsScripts Naming Convention Scripts should be named so that their relationship to the Application Under Test (AUT) is easily identified. In Caremark testing environment, QTP scripts are named according to the following convention: Driver script should be named as: {Ex: PeopleSafe_Driver} Reusable Action Naming Convention All actions designed for the Caremark applications are reusable to allow the code to be reused. The naming convention used for Reusable actions are . For e.g.: PS_Voluntary_Log_Activity where PS PeopleSafe Acronym and Voluntary_Log_Activity-Business Function Data Table and Data Sheet Naming Convention All Test data in Caremark Automation Architecture are stored in databases as data tables or excel workbook as data sheets. Databases and Data tables that contain the script data should be given a generic name which specifies the AUT and one data table /data sheet for should be created per business function. The following naming convention needs to be used to define data tables < AUT_Acronym_ApplicationFunction> Ex: PS_Account_Balance where PS PeopleSafe Acronym Account_Balance -Application Function

10:00:00 AM

Last Updated 4/24/2009


Constants Naming Convention Constants are symbolic names for values that never change within your code. Constants names should be in uppercase characters. Multiple words have to be separated using the underscore (_) character. Do not use abbreviations or any spaces in defining constants as it might cause errors while retrieving values from the constants in the program. Use descriptive names to convey its intended use. Here are some examples: public const FILE_PATH public const SAVE_BEFORE_CLOSE Variables Naming Convention Variable Naming Convention Variables are used to represent and manipulate dynamically changing data in a script. They are used extensively throughout the code. To maintain and modify code, it is essential to understand what the variables do. As a result, the variable standards are aimed at clearly communicating the purpose and intent of variables. The following convention should be followed while defining variables: The variable name should always begin with an s, n or d specifying whether the variable holds a string value, a numeric or date value respectively. Ex. sUserName specifies that the variable stores a string value and nCheckNumber specifies that the value stored in the string is a numeric value. Use mixed-case variable names to help make them more readable. Start each piece of the variable name with a prefix specifying if it is a string or a number followed by a noun-adjective format to make it for descriptive. This naming approach makes it much easier to visually browse through script code when writing, debugging, or otherwise maintaining it. Caremark Automation environment all data is retrieved from tables and data sheets via dictionary objects. The naming convention for dictionary object items / variables should follow the same naming convention as above. All dictionary objects should begin with a naming convention to specify that the object is a dictionary object. E.g. Set dicEditData = CreateObject (Scripting.Dictionary)

Action Parameters Naming Convention QTP allows user to define Input and Output parameters. The following naming convention needs to be used for defining Action parameters Input Parameters All input parameters should be named with the following convention specifying that the variable is an action input parameter. For e.g. pUserId. Output Parameter All output parameters should be named with the following convention . For e.g. pOrderNumber. Last Updated 4/24/2009 4

10:00:00 AM

Environment Variables Naming Convention All user defined Environment variables should be named all capital with the following naming convention Environment (PARMATER_NAME) .Please note the parameter name in the Environment variable should be all caps and the user is allowed to use special characters. For e.g. sUserId = Environment (CURRENT_USER_ID) Functions Naming Conventions Caremark Automation environment VB functions are developed in the function library for any repeatable task which might be used in multiple scenarios. As with the rest of script elements, functions also require descriptive names. Since functions are designed to carry out some action, the descriptive names have a slightly different focus. Function names should begin with an action word. As with the variable naming convention above, use mixed-casing for multiple words as a standard for naming functions. Here are some examples: GetDataFromExcel (sFile,sQuery,dictionary) CreateFolder ()

Coding StandardsComments Comments are used to indicate the intent of a script, or of a particular statement or a function. Comments are used to document what the script does and what specific lines of code do. They prove in valuable whenever a tester inherits someone elses code that requires modification or maintenance as the associated application changes. Comments are used to create headers for each script and function. Every script should have block of codes with comments which should be as brief and precise as possible while remaining descriptive. In Caremark Automation environment comments are added for the following sections of code:1. Script Header should always begin with a block of comments which describe a.) Script Name Name of the Reusable Action b.) Author Responsible person for developing the script c.) Creation Date Date the script was created d.) Description Describe the Business function automated in the script. e.) Notes Additional notes such as Number of Test Cases, Data Tables created etc. should be added to this section.

10:00:00 AM

Last Updated 4/24/2009


2. Modification Log should always be added after the Script Header to document any enhancements made to the script along with the date and block of code modified. The modification log should include the Name analyst responsible for modifying the script , Date the date script was modified ,Description the block code modified and the business function / project for which the change is made. 3. Data retrieval section should be clearly documented in the script. The analyst should ensure that any block of code which retrieves data from the Database or the data tables should be highlighted with comments defining which tables are used to retrieve data. 4. Comments should be used for all instances where Conditional Statements are used clearly indicating the start and the end point of the statement/loop and the business function for which the Conditional Statement is being used. 5. If a function is particularly complex, comments are used to explain the type of data the function is retrieving and the input parameters that are used. 6. The script should be divided into block of codes with comments clearly indicating the business functionality that every block represents. Examples: 1. Script Header / Modification Log

10:00:00 AM

Last Updated 4/24/2009


2. Data Retrieval Section

Data Tables and Data Retrieval In Caremark Automation Environment all test data is stored in Database tables or Data Sheets. One data table is defined for every business function or screen with appropriate data. Data is retrieved from all these tables using Dictionary Objects. The following rules are used for data retrieval 1. All test data unique for one test case or scenario is stored in one data table and retrieved using dictionary objects. These tables are defined as slave tables. 2. All reusable test data which need to be used in multiple scenarios are stored in master tables and retrieved using dictionary objects. Different scripts which need the data need to query these tables to retrieve the test data. This normalization process is used to reduce data redundancy. 3. Dictionary Objects are defined as per the Windows Scripting Host standards t