CVS Caremark Automation QTP Scripting Standards

Information TechnologyScript Design Specifications

Version 6.0 February 5, 2009

Document Information

Project Name QTP AUTOMATION SCRIPTING STANDARDS

Author(s) Rohan Patnaik

Contributor(s)Dan Marek , Vivek Bhanot , Radha Rao , Vijay Nori , Chandra Vadamodula , Lakshmi Chadive , Chisore Nyirenda , Mark Esposito , Shama Narasimhan, Maria Vandermeersch

First Issued On 26 December 2007

Version Number

6.0

Last Updated 03/22/2008

File Path/Name

History

Date Version Author Contributors Changes

12/26/07 1.0Rohan Patnaik

NA Initial Draft

01/07/08 2.0Rohan Patnaik

Dan Marek , Vivek Bhanot

Added updated information for Naming Conventions , Data Retrieval Steps

01/09/08 3.0Rohan Patnaik

Dan Marek , Vivek Bhanot

Added Script Design Section

02/01/08 4.0Dan Marek

Enterprise Regression Team

Added updates after review with the Enterprise Regression Team

02/05/08 5.0Dan Marek

Enterprise Regression Team

Added Error Handling Naming conventions

03/22/08 6.0Rohan Patnaik

Enterprise Regression Team

Added Modular Automation Framework Design Details

[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 Standards

A 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 Conventions

Scripts 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:

<ApplicationUnderTest_Driver > {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

<AUT_Acronym_ApplicationFunction>.

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 AcronymAccount_Balance -Application Function

Last Updated 4/24/2009 11:00:00 PM

3

Constants Naming ConventionConstants 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:

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 <dic> 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 “<pNameofParm>” 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 “<pNameofParm>”.

For e.g. pOrderNumber.

Last Updated 4/24/2009 11:00:00 PM

4

public const FILE_PATH

public const SAVE_BEFORE_CLOSE

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:

Coding Standards

CommentsComments 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 else’s 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.

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.

Last Updated 4/24/2009 11:00:00 PM

5

GetDataFromExcel (sFile,sQuery,dictionary)

CreateFolder ()

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 –

2. Data Retrieval Section

Last Updated 4/24/2009 11:00:00 PM

6

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 to store strings of data

4. ADODB connections are used to iterate and store data from the tables into dictionary objects.

5. Data is retrieved from the dictionary objects by using the Item property and then passed to variables in the AUT.

6. As per the standardization process, the variables names used in the script are named same as the column headers in the table to make the script easier to debug.

Ex. sBeneficiary is the name of the column header in PS_Beneficiary_Info table and same variable name is used in the dictionary object to indicate the data stored in the variable

Data retrieved from the tables is then iterated through the script to validate the business function.

Last Updated 4/24/2009 11:00:00 PM

7

Control Statements

General VB Control Statements are used in all scripts for all repetitive and conditional operations. The following rules are defined for declaring various Control Statements in the script –

If/Else - This conditional statement is used for conditions in which only one or two conditions need to be validated for executing a particular business function. Note the number of conditions to be validated should never exceed 2.

For Next – This control statement is used for iterating through set of data. Generally “For Next” loop is used in the script to iterate through set of data retrieved from data tables.

Do Until – The Do until Loop is used to execute a particular function until a particular condition is met.

Do While – The Do While loop is used to execute a particular function as long as a particular condition is true.

Switch Case – The Switch Case statements are used in cases where the number of conditions is more than 2 and the If/Else loop fails to meet the conditional statements. A switch is used for each condition and based on the condition passed a set of steps are executed.

Function Libraries

In Caremark Automation Environment all designed functions and subroutines are stored in a central repository. All QTP functions are designed using VB coding standards.

The automation framework uses libraries of reusable code logic that can be called by other scripts. These libraries contain functions that are common to individual applications, multiple applications, or completely generic to the AUT (e.g. file manipulation routines). The functions are data driven using parameters and do not contain QTP objects, this will ensure the functions are reusable and easy to maintain.

Every function in the Function Library is defined with a header file. The Function Header file contains the following –

Function Name – Name of the Function defined as per the naming conventions

Created By – Name of author who created the function

Date Created – The creation date of the function

Description – Brief description of the operation that the function performs

Parameters – The parameters which need to be passed into the function from the application

Returns – Any parameters that the function returns to calling statement. Please note fro Subroutines this is “Not applicable”

Last Updated 4/24/2009 11:00:00 PM

8

All developed functions that are being used by the Automation framework need to be updated in the Function Repository for version control purposes. The function developed by user needs to be updated in the appropriate categories in the Function Repository document currently stored at :- \\ilbbfsp00\all\Regression\Automation\Libraries\Function_Repository.xls

Error Handling

In Caremark Automation Environment various Recovery Scenarios and Error Handlers are used to handle unexpected application issues and any changes to the learned objects. The following Recovery Scenarios for the AUT –

Unexpected Pop Ups – Design Recovery scenarios to take the screenshot of the error and store on the machine’s local C:\ drive and exit the action. All errors are logged as screenshots in the local C:\ drive.

Object Repository Errors – Any errors in the stored objects in the object repository are logged and the script skips the operation on the object. If the script fails to advance then the Pop Up Recovery scenario is invoked and the script then skips the test scenario and executes the next scenario in the iteration

Application Crash - If the Application under Test crashes or if there is a critical error then the script should take a screenshot of the failure and stop QTP execution.

Generic Exception Handler - Use of a generic exception handler is recommended. Errors are logged centrally, and an event handler, also maintained in a central repository, is used to deal with specific error conditions. The runtime errors in the QTP scripts are handled by using the statement "ON ERROR RESUME NEXT". This statement should always be at the top of the script. When this statement is executed, any runtime errors will be silently trapped and stored in the global Err object and execution resumes on the next statement.

Last Updated 4/24/2009 11:00:00 PM

9

Error Message Convention –

o AppAcronym -- Application Acronym

o TestCaseName -- Name of the test case executed

o BNFID - Particpant ID

o TimeStamp -- time in 00:00 mm/dd/yyyy format

o Message -- Free form field

Exit Script on Error Convention – When exiting a script on error return 1 for fail ex. ExitAction(1)

Script Design

All automation scripts designed in the Caremark Automation Environment need to have the following sections:-

Initialization and Data Retrieval Section - All variables that are to be used by the script are declared and initialized at the beginning of a script. This facilitates script maintenance and ensures that values are set to an expected state at the outset of test script execution.

All data retrieval statements which use SQL to retrieve data and the dictionary objects should be a part of this section as well.

Business Section – All recorded statements, iteration loops and control statements which define the business flow of the script are defined in the business section. This ensures that code is clearly separated from the initialization and data retrieval section.

Exit Section – All WSH and QTP objects referenced in the Data Retrieval and the Business Section have to be set to “Nothing” to release all system and memory resources referenced by the object. This ensures better script execution and performance.

New Script Development Standards

All New Script Development should be based on the standardized QTP Settings developed at CVS Caremark. These QTP settings are set of rules at every QA Automation Engineer has to follow ensuring all developed scripts , object repositories and function libraries are consistent across the enterprise / project enabling easier script management. The New Scripts Development Standards follows the QTP Object Model and imposes the following set of Automation Rules as described in the attached Excel spreadsheet :-

Last Updated 4/24/2009 11:00:00 PM

10

Automation Framework

All QTP Automation scripts at CVS Caremark are implemented using Modular Data Driven approach. This framework is a hybrid model of Application Functional Decomposition and Data Driven approach in which each Business component is divided into the smallest modular component enabling faster script development, easier maintenance and more scalability. The details of this framework are as described below :-

Modula Data-Driven Automation Approach:The Modular Automation approach uses Microsoft Access Database or Microsoft Excel to interface with Quick Test Professional (QTP), which in turn interacts with the AUT to execute the automated test scripts. Each baseline QTP script will be broken down into modules based upon the AUT layout. Breaking the baseline script into modules will allow for easier development and maintenance will be less time consuming. The basic concept of Modular approach can be outlined as below:-

Modular Approach = Functional Decomposition Framework + Data Driven Approach Divide the application into groups of related activities or steps called Reusable

Actions. Generate scripts called modules that take care of these Reusable Actions with

data driven capability. Integrate the modules in the required order into actual scripts called flow or

Driver Scripts.

Functional Decomposition

The main concept behind the "Functional Decomposition" methodology is to reduce all testing efforts involved in the application in to their most fundamental tasks, and write re-usable functions/ scripts, which perform these tasks independently of one another. The actual scripts will call these functions as needed. This part of the modular design provides re-usability of code/functions in multiple test scripts yet provides centralized control for effective test management.

Data drivenThe “Data driven” part of the modular approach provides re-usability of main scripts (created using re-usable functions/ scripts) across multiple data sets/scenarios/transactions.

Advantages: Allows the bulk of the requirements analysis, test strategy, scenarios, conditions (test

plans) and data (test cases) creation to be conducted by the quality control analysts who have the most business knowledge.

Allows the bulk of the automated test execution and automated test run analysis using QTP to be conducted by the quality control analysts who greatly seek this automated test execution and analysis skill set to compliment their extensive business knowledge.

Since most project requirement changes are addressed by data updates, this allows the changes to be conducted quickly with the use of the Access Database /Excel Spreadsheets as part of the test planning phase by the quality control analysts who have the most business knowledge.

With test scenarios being written in the form of data test cases using the Access Database / Excel Spreadsheets, the quality control analysts can execute them either

Last Updated 4/24/2009 11:00:00 PM

11

manually or via automated methods when executing the automated test scripts that are driven by the data test cases.

Allows the AUT Automation team to create a top-to-bottom scripting model that greatly reduces the number of scripts to be maintained to just a handful. This way as screen changes or major application changes come in, they can be addressed by updating a few global lines of script that apply to all the data test cases instead of having the same line of code embedded in each script and requiring a tremendous amount of effort to update and maintain.

Appendix

Last Updated 4/24/2009 11:00:00 PM

12

CVS Caremark Acronyms

The following acronyms are used for the Caremark Applications under test and need to be followed for all naming conventions –

Acronyms DetailsPS PeoplesafeMOR Mail OrderPOS Point of Sale

Abbreviations

The following general abbreviations have been used in this document.

Abbreviations DetailsQTP HP Quick Test ProfessionalAUT Application Under TestVB Microsoft Visual Basic

WSH Windows Scripting Host

ADODBActiveX Data Objects

Database

Document Location –

The updated version of this document is stored at – TBD

Last Updated 4/24/2009 11:00:00 PM

13