Business Framework

Automated Test Suite Architecture Guide

Effective Date: Authorized By :

Responsible Parties
Process Owner Title/Role/Functional Organization

Contributors

Title/Role/Functional Organization

Stakeholder
Name Title/Role/Functional Organization

Last Revised: 1/16/08

Automated Test Suite Setup and Execution Guide.doc Proprietary and Confidential OfficeMax

Page 1 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Contents
Purpose ......................................................................................................................................................... 3 Definitions ..................................................................................................................................................... 3 Automated Testing Framework Overview..................................................................................................... 4 Test Suite Directory Structure....................................................................................................................... 6 QTP Configurations....................................................................................................................................... 7 Automated Test Suite Standards .................................................................................................................. 9 Coding Style Best Practices ................................................................................................................... 9 Documentation & Standards ................................................................................................................... 11 Revision History .......................................................................................................................................... 14

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 2 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Purpose
This guide provides instructions for installing, preparing for and executing the automated regression test for Policy Center.

Definitions
Term Automated Test Framework (ATF) Definition All test automation entities required to execute automated test cases including all QTP entities (scripts, functions, object repository, etc.) and associated data input files. Application Under Test the application being tested during an execution of the automated test suite. The AUT state that each test case expects to find the when it begins to execute. The state that each automated test case will leave the AUT in when execution is complete. Any QTP script, action or function that executes test cases / business processes. A single set of instructions (steps and data) that execute actions and verifications necessary for performing a single test case. A set of Automated Test Cases grouped together for a single Test Run. A single execution of the automated test suite. A series of test scenarios run sequentially as part of a test cycle. Any event encountered by a Test Entity that, if not detected and addressed, would cause execution to be stopped. A QTP test entity that executes a specific business process (or part of a business process) of the application under test. A QTP test entity that executes a specific verification action on the AUT required by test cases. A QTP test entity that executes a specific low-level action typically a single user action on a user interface object.

AUT Initial State End State Test Entity Automated Test Case (Test Case)

Automated Test Scenario (Test Scenario) Test Run Test Set Unexpected Event

Business Process Function (BPF)

Verification Function (VF) Keyword Function (KF)

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 3 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Automated Testing Framework Overview

The automated testing framework (ATF) provides a foundation for efficiently implementing an effective test automation solution. The framework, shown in Figure 1, consists of an automated test engine (built on HPs QuickTest Professional solution) and driven by external data files. The external data files contain instructions that govern the execution of test cases and scenarios. Each component of the ATF is described below.

QuickTest Professional (QTP)

Driver Data Files

Environment File

Driver

Automated Test Case Files

Test Case Interpreter

Test Results

Business Process / Key Word / Verification Functions Application Specific | General Web

Utility Functions

Object Repository

Figure 1. Automated Testing Framework ATF Component Driver Test Case Interpreter Description A QTP script that reads Driver Data Files to determine the set of Automated Test Case Files included in the test scenario to be executed. A QTP action that reads the instructions contained the Automated Test Case Files and calls the appropriate Business Process, Keyword or Verification functions.

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 4 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

ATF Component Business Process, Keyword and Verification Functions

Description Business Process Function: A QTP function that performs a series of steps specific to an applications business process (e.g. Login). Keyword Function: A QTP function that performs a generic step for a particular application type (e.g. click_link). Verification Function: A QTP function that performs validation (e.g. compare values). Functions are divided into three groups: 1. Application Specific - functions that perform business processes, keyword actions and verifications that are specific to the AUT. They generally are not reusable across automated test suites 2. General Web functions that perform keyword actions and verifications that are general to most browser-based applications. 3. General Terminal Emulator (TE) functions that perform keyword actions and verifications that are general to most TE-based (i.e. green screen) applications.

Utility Functions Object Repository Driver Data Files

QTP functions that perform general framework operations such as error handling, results reporting, data handling, etc. A QTP entity that maps GUI object local names to their physical descriptions to enable object identification during execution. Files that contain the set of Automated Test Case Files that are executed as part of a test scenario. In addition to the path and name of the Automated Test Case Files the Driver Data Files contain the Environment File that is associated with each Automated Test Case File. A worksheet within an Excel workbook containing the instructions for executing an automated test case. An XML file containing the environment settings required by a specific Automated Test Case File.

Automated Test Case Files Environment File

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 5 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Test Suite Directory Structure

The figure below depicts the file structure that houses all of the necessary components of the test suite:

Figure 2. Automated Test Suite Directory Structure

Directory AutoResults Data

Description This directory contains all execution results. The data directory contains all necessary data files for the Driver and PolicyCenterAction scripts to execute the business process tests. This folder contains the documentation files for the ATF. This folder contains the xml files for each environment that will be tested. The XML files contain all static environment variables required by the ATF. This folder contains the library files that house the reusable functions and subroutines. The Obj Repository directory houses the shared object repositories used by all automated tests. Currently, the architecture contains two (2) repository files, SP2.tsr and TERep.tsr. SP2.tst contains object definitions for accessing the Policy Center application, and TERep.tsr contains the object definitions for accessing the terminal emulator for the WC Pledge application. This directory contains error handlers to supplement the Driver and PolicyCenterAction scripts in an event of an unexpected occurrence during a test run (e.g. a pop-up dialog box or a Page not found error). Currently, there are no recovery scenarios that have been defined for this implementation. The ScreenMap folder contains the database that stores the mapping locations of the terminal emulator (TE) screen fields.
Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax Page 6 of 14

Documents Environment

Lib Obj Repository

RecoveryScenarios

ScreenMap

Last Revised: 11/01/08

Business Framework

Automated Test Suite Architecture Guide.doc

Directory Scripts

Description The Scripts folder contains the QTP scripts necessary for the automation: Driver and PolicyCenterAction.

QTP Configurations
The following table describes the required QTP configurations: Area Folders Description QTP can set the root directory path for the test suite. This setting must be set in the Driver file under Tools>Options>Folders. An example of the path that would be set is C:\Work\SP2. The directory structure listed inside of this directory would be the folder structure pictured in Section 2. When the test suite is moved to another computer or another directory, it is necessary to confirm that the binding to external actions that occurs within the Driver script still exists. To do this, open the Driver script in QTP. The following datatables should exist as tabs across the bottom: Global, Driver, and PolicyCenterAction [PolicyCenterAction]. If either of the last two tables does not exist, go to the very top line in the script. From the toolbar select Insert>Call to Existing Action. In the From test drop-down, select either PolicyCenterAction from the directory where it resides. If it is not found in the drop-down, browse for the script. Change the path to a relative directory (e.g. ..\..\Scripts\PolicyCenter\Action1). Press the OK button and when you return to the script there should be a new line of code that starts with the statement RunAction. IMPORTANT: Delete this line of code and save the Driver script.

Calls to External Actions

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 7 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Area Resources

Description Shared Object Repositories The path to the shared object repository must be correct in both QTP scripts (Driver and PolicyCenterAction). First open PolicyCenterAction to verify that the shared object repository is found. If it cannot be found a message should pop-up upon opening the test and you can browse to the new location of the repository. Then open the Driver script to do the same. There is another place to specify where the shared object repository is located as well. In Resources>Associate Repositories there is a section called Repositories. The directory to the repository should be specified as ..\..\Obj Repository\SP2.tsr and ..\..\Obj\Repository\TERep.tsr. Function Libraries In Test>Settings>Resources there is a section called Associated library files. There should be three entries in this location for the libraries. This includes: ..\..\Lib\Web_lib.txt ..\..\Lib\PolicyCenter_lib.txt ..\..\TE_lib.txt

Handling Guidewire Applications

The PolicyCenter application is built using a third party package from Guidewire. Since Guidware code is automatically generated, some of the objects can be difficult to identify. One particular challenge is working with tables, which are used extensively in the PolicyCenter application. There are a set of AFT functions specifically developed to work with tables. Column name is used as the primary means to identify tables. The column name is passed as a parameter and the functions search for that label to locate the table. If more than one table with the same label is present, an instance parameter is required to determine which instance of the object to use. Please refer to the Quick Reference Guide for detailed explanations of the table functions. Most of the Guideware objects have an additional attribute called SmokeId. In some instances, the SmokeId can be used to identify the object. The SelectTopNav function takes advantage of the SmokeId to select the correct top navigation button.

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 8 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Automated Test Suite Standards

Coding Style Best Practices
When developing QTP scripts it is important to follow the naming conventions. This will allow code reviews and maintenance more efficient and effective. We shall follow CamelCase and a modified form of the Hungarian Notation. CamelCase, camel case is the practice of writing compound words or phrases where the words are joined without spaces, and each word is capitalized within the compound (e.g. SelectPolicy, StartState, etc.). Use the following standard prefixes to denote data type. o Object obj objRecordset o String str strFirstName o Integer int intLoopCounter o Array arr arrRowHeader o Date dte dteBrithday o Boolean bln blnLoggedIn o Global (public) g_ g_SavePath

Assign meaningful names that will be easy to remember as you code.

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 9 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Coding Style Best Practices

Code Area Coding Layout Description Use a single statement per line All statements should be clearly arranged on a separate line. Concatenation of multiple statements per line using the ":" separator must be avoided. Use line continuation characters to break long lines To aid readability, an individual source line must not exceed 85 characters in width without the use of the line continuation character ("_"). Statements must use indentation Indentation is another technique that improves readability of code. Indentation is especially helpful in areas such as if statements and for/do loops. Single line "If...Then" statement must not be used In the interest of making source code more readable, single line If...Then statements are to be avoided (i.e. the 'End If' keyword must be used for all 'If' statements). Location of variable declarations To aid code readability, all local variables must be declared at the head of a procedure. Location of constant declarations All constant declarations must appear before variable declarations within the declarations section of a source file. Location of "public" and " constant declarations All Public constant declarations must appear before private constant declarations within the declarations section of a source file. Nested If...Then statements To ensure that procedures are easy to understand, test and maintain, 'If...Then' statements must not be nested beyond four (4) levels deep. Excessive variable declaration To keep procedures simple to read and understand, try to avoid declaring excessive numbers of local variables within a procedure. Nested select statements To reduce code complexity and improve code readability avoid nesting Select...Case statements within other Case statement blocks. If the Case statement needs to perform conditional or complex logic, consider rewriting the code as another separate function.

Coding Complexity

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 10 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Code Area Comments

Description Constant declarations must include a comment header All public and module-level constant declarations must include a standard comment header describing what the constant value represents and how it is to be used. Comments within procedure code blocks Code statements within procedures should be interspersed with comments to describe the logical operations being performed by the statement blocks. Comments should not merely echo the physical code. Procedure comment header All procedures must include a standard comment header describing what the procedure does as well as details of any arguments used and return values. Format of procedure header comments Procedure header comments must take the following form: opening comment separator line, procedure name, created by, date created, one or more lines describing the procedure followed by individual argument names and descriptions, one or more lines of describing return values (including any errors raised by the procedure) and ending with a closing comment separator line. Use reminder comments Whenever an issue within source code is identified which cannot immediately be resolved, a reminder comment may be inserted into the source to ensure the issue is not forgotten. Comments beginning 'TODO: will be treated as reminder comments and should describe the issue appropriately including the name of the developer responsible for the comment and the date the issue was identified. User-defined type definitions must include a comment header All user-defined type definitions must include a standard comment header describing what the type represents and how it is to be used. Variable declarations comments All public and module-level variable declarations must include a standard comment header describing what the variable represents and how it is to be used.

Documentation & Standards

The following tables describe coding documentation and standards:

Naming Conventions
Area Application Object Names
Last Revised: 11/01/08

Description Object names should capitalize the first letter and follow the CamelCase convention. (e.g. objBrowser)
Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax Page 11 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Area Variable Constants Functions

Description When naming a variable, capitalize the first letter and follow the CamelCase convention. (e.g. strFirstName) All letter of a constants shall all be CAPITALIZED. When naming a function, capitalize the first letter and follow the CamelCase convention. All functions shall have proper function headers.

Documentation & Standards

Area Test Case Input Test Case Output Description Use Excel Files as the data source for all use cases. The template will be the same across all Streams. Use Excel Files as the data source for reporting results for individual test cases. QTP results should also be stored and saved. Each test script must handle any exceptions that can occur during the test run. The PolicyCenter test script header shall contain: Name Type Main Reusable Action Description Author Create Date

Error Handling Documentation PolicyCenter Actions

Sample ******************************************************************** Name: Type: Description: Author: Create Date: ********************************************************************

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 12 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Area Documentation - Functions

Description The functions shall be written using VBScript. The function header should contain: Name Parameters Specify the parameters used by the reusable action. Indicate any optional parameters o IN Describe any input parameters o OUT Describe any output parameters o RETURN Describe any return parameter Description Created By Create Date

Sample '************************************************************************ 'Name : 'Parameters: ' Returns: Desc: 'Created by: 'Created on: IN IN WriteExcelReport(ScriptName, TestResults, Remarks) Script Name - This is the name of the Script that is calling this function TestResults - This takes "Fail" as the results parameter for only the failed Transactions. Remarks - This takes the Remarks Field of the Failed Transactions as to why the Transaction failed. N/A Writes the Failed Transactions Test Results into an Excel Report. Utopia Solutions 11/15/2007

IN

'*************************************************************************

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 13 of 14

Business Framework

Automated Test Suite Architecture Guide.doc

Revision History
Content Revision History - PAL ID:
This log stays with the completed document to track published revisions to the content. Version Date Revision Description Revision Author

Last Revised: 11/01/08

Automated Test Suite Architecture Guide.doc Proprietary and Confidential OfficeMax

Page 14 of 14