AUTOMATION STANDARDS

This Document contains below Concepts:

 FOLDER STRUCTURE AND NAMING CONVENTIONS

 PRE SETTINGS

 GENERAL SCRIPTING

 EXCEPTIONAL HANDLING

 CORELIB

 DOCUMENTATION
 FOLDER STRUCTURE AND NAMING CONVENTIONS

In order to ensure that our Project Suites are compatible on the various

environments and run with the minimum maintenance the following standards

have been set for all scripts.

1. Project Suit Folder structure

Project Suit Folder should contain

a. Config.xlsx

b. Test data Folder

c. Test Cases Folder

d. Documentation Folder

e. Results Folder

f. Read Me Folder

Automation Scripts – Folder should contain the actual scripts for modules in Project

Suite.

2. Project Suite Naming Convention:

Project Suite Name: ProjectSuite_GA_ModuleName_Vxx

Project Name: GA_ModuleName_SubModuleName

Units Names: DriverScript

TestCasesScript

DataBaseScript

TestDataScript
3. UNITS:

• Test Case Script: Includes functions for Edits validations.

• Driver Script: Includes Main functions which call Edits and DB functions as per

Module.

• Database Script: Includes DB validations scripts (Add, Change and Delete).

• Test Data :

– Includes Add data without reporting to Result File

– Fetching existing and non existing data functions.

– If data fetched successfully pass is reported to test data Result File.

– If Fail is repotted to Test Data result file represents data not available in

database.

– Main function containing all these functions is called from driver script.

– Refer project suite at \\10.1.0.145\WebQC\Automation Testing\QA Automation V35

Scripts\Sample_PhaseV\Read Me

• Each unit should contain below comment template:

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

'Module name        :

'Description              :

'Date of Creation :

'Author                          :

'Last Modified by :

'Date Modified                        :
'Comments                                :

‘UPN Version:

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

4. Always have method and variable names crisp and meaning full.

Method naming hierarchy and Result file naming formats are available in Standards

PPT.
 PRE SETTINGS:

1. Make sure that you login (in environment to be tested) and maximize UPN. See that

there is only one UPN process and no Excel processes running in your system Task

Manager.

2. Always make sure Config File has same environment settings of the environment in

which UPN is launched.

3. See that Stop On error option is unchecked in all project properties->Play Back option

so that script does not stop due to minor changes like option existence.

4. See that Project Properties->Visualizer->Use Test Visualizer during recording and

test run are unchecked, so that its saves memory space used to store screen shots

associated with every step in script execution and recording.

Some more tips:

http://support.smartbear.com/articles/testcomplete/test-playback-performance-

tips/#tip_1
 GENERAL SCRIPTING:

1. Use global constants to pass data into scripts and between scripts.

2. Make use of main menu selections over toolbar items whenever possible. (Ex:

CA/GA and then sub module selection in it.)

3. Do a window existence test for every window opened by script; this will prevent

scripts dying from slow client/server calls. (Synchronization)

Have delay after every Excel Read and Write functions as Excel process need to close at

back end.

4. Comment all major selections or events in the script with its description. This will

make debugging easier.

5. Once fetching the details from the Server is complete always close the connection

string. Have single connection and closure if multiple queries need to be executed.

6. While preparing test data try to create script for test data based on the necessity.

When script is trying to retrieve the existing data, if no proper data exist in the back end

stop the script execution by displaying a message to the user no proper data exist to test

the module.

7. Always delete the data we have created by script for various validations so that it

does not create junk data in database.

Don’t create any new data if data existing in DB that can be used.

8. For controls with in a panel/section can have a single parent object. It will help in

script readability/maintainability. We can use object name preceding the actual object

name if there are more than 1 object with same name.

9. Database script unit is to be used for pure DB interactions. All the local variable and

methods can be included in Test cases script unit.

Through this we can avoid referring Driver_Script in Database script unit and Test

cases script unit.

10. Every script should be tested with screen shot flag ON and OFF in Config File before

closure and also helps in step fails description during designing scripts.

11. If certain validation is not done a particular test object (Server side edits) due no test

data, report it to result file as Skipped, so that it can be addressed if possible and also

shows that we have tried to validate that functionality.

12. Manual testing scenarios of objects present in the window like Enabled, Length,

Exists etc.. Should be included as Object Properties Verifications section.

13. Do not have any name mapping in your project suite.

14. Always develop your scripts in latest Environment(Test Plus) so that our scripts are

up to date.
 EXCEPTIONAL HANDLING:

1. Use GeneralEvents_OnUnexpectedWindow script to handle unexpected windows

during script execution.

2. Use if not Recordset.BOF AND not Recordset.EOF to check data existence instead of

only Recordset.EOF in DB data fetch scripts, so that there is no VB script error when we

try to fetch data which is not available in DB.

3. It is preferable to check for the data is not empty on which Data conversion/data

comparison functions are applied.

4. Make a call to DisplayCustomError method in local scripts to log VB Script errors.

This function need to be called for all functions in your script to log VB script errors,

cannot be placed in CoreLib as Err object can be identified only in local scripts.
 CORELIB:

1. Do not Save in the test procedure in CoreLib, unless it is necessary and reusable, this

will prevent the need to write numerous clean up scripts. Avoid using static objects in

the functions; instead use functional parameters making the function re-usable all over

the application.

2. Create a template header to the functions in UPN_CoreLib. This comments template

can be used for modification tracking and commenting on the script.

3. Before adding a function to Core Lib ensure that the function does not create

duplicate functions.

4. If any function can be upgraded with new feature and needs to add a parameter to it,

add it as a separate function as change in number of parameters affects previous scripts

using the function.

5. If function is related to framework modifications mail it to the team and then modify

the CoreLib by including team suggestions.

 DOCUMENTATION:

1. Project suite should contain ReadMe and UPN Documentation

2. All the information User should know in order to execute the Project Suite need to

include in the ReadMe doc. Information regarding Module description, Scenarios not

automated etc.. can be placed in Documentation document.

3. Test Cases document describing Auto and not auto Test cases along with description

for Not Auto scenarios should be available in Project Suite in Test Cases Folder.

REVISION HISTORY

Version Date Reviewed By Description

Number
1.0 10/29/13 Joy Chirackal Initial