The Conventions for Naming for test cases, Scripts and Actions vary from Project to Project depending upon the Client.
Test Case Naming Conventions: Test cases should be named in a manner that enables easy identification of the corresponding Use case (or the Scenario) for which the Test Case is written. The Onlooker should be able to trace the test case back to the use cane name or Scenario name by the name of the Test Case. Consistency should be maintained in following the hierarchy of naming. For example, if each use case is associated with one test case and if the name of the Use Case is UC_001 then the test case name would be TC_001.
Script and Action Naming Conventions: Similar to the Test case naming, Script naming should be done consistently with clarity and traceability. Typically each Test Script is prepared corresponding to each Test Case. Every Test Case contains one or more Conditions. Each Condition can be represented by an action in the script.
Therefore for a Test Script corresponding to a Test Case named TC_001 would be QTS_001. The hierarchy should be maintained in case the use cases or test cases are nested. For example TC_01_014 would have a QTP Test Script as QTS_01_014.
Action Naming: Each Test Script can contain one or more Actions, with one or more actions representing a test Condition. Actions can be named in 2 ways:
- Functionality of the Action
- Hierarchy of the Action in the Test Script
Functionality of the Action: Typically Actions are segregated by their functionality in the Test Script. Therefore it would be easier to understand the Action if the name of the action represents the Functionality.
For example, an Action written or recorded for logging the user should be named as Login or Authentication for easy understandability.
An Action for booking tickets should be named as Book_Tickets
An Action for exiting the application named as Exit.
This also adds a huge advantage when the Actions are made reusable. Reusable Actions can be used between various scripts. When an Action is to be made reusable the action should be named as REUSE_(Action name). Example: REUSE_Login
Hierarchy of the Action in the Script: Since Actions are a part of the Test Script, for purpose of Clarity and tracking, Actions can be named as per Hierarchy.
For example:
Test Case Name: TC_01
QTP Test Script Name: QTS_01
Name of 1st action in the Script: QTS_01_01
Similarly Name of 9th Action in the Script: QTS_01_09
Variables and Constants: QTP Scripts are in VB Script. Therefore, the naming conventions for variables can be followed alike VB Script Naming Conventions.
General Conventions followed in VBScript are:
- Data Type Prefixes: By using data type prefixes, your variables always indicate what they are designed for
- Constants Prefix: Usually there are only a handful of constants in any scripts. Indicating the data type therefore is less important for constants. Prefix letter c for all constants can be used.
DataSheet Naming and Parameter Naming Conventions: Every QTP Test Script contains 2 types of sheets
- Global data sheet
- Local data sheets
The Global data sheet, which is a common sheet for all the actions of the script, is named by default as dt_globalsheet. This can be renamed as Global for all the Scripts for consistency.
Typically, Each Action in the Script contains one data sheet, which is local to the Action. This is by default, named after the Action to which it belongs. Therefore the name of the datasheet follows directly the name of the Action, which when named following its naming conventions, can be used efficiently for the data sheet too.
Parameter Naming: Various Types of Parameters used in QTP are:
1. Test Parameters:
- Test Input Parameters: These should be named as IN_(relevant variable name). ‘In’ denoting that it’s an input parameter for the Test in whole. The name following IN should be a relevant name for the variable, denoting the purpose of its use. This should also comply with the standard variable naming conventions. Example: IN_bFlag, IN_iIncrement etc.
- Test Output Parameters: On the similar lines of Input Parameters, these should be named as OUT_(relevant variable name). OUT representing that it’s an output parameter. Example: OUT_sStatus.
2. Action Parameters:
- Action Input Parameters: These are local to Action of a Test. These can be named as ACTIN_(variable name). ACTIN denoting that it’s an Action Input Parameter.Example: ACTIN_iResult.
- Action Output Parameters: These could be named as ACTOUT_(var name).Example: ACTOUT_bFlag
3. Environment Variables: Environment variables are either built-in or User defined. Built-in variables cannot be declared named by the user, so their naming convention is not discussed.
User Defined Environment Variables are either Internal or External.
Internal Variables: ENV_INT_(variable name)
External Variables: ENV_EXT_(Variable name)
Function Naming Conventions: Functions should be named as Func_(name). This can provide clarity and difference between a Reusable Action and a Function that can be used within Actions.
Example: Func_Save , Func_Add
Also See:
- WordPress Web Hosting for Small Businesses: Essential Tips - October 3, 2024
- Web Hosting for Online Startups: Scalability and Reliability - October 3, 2024
- 4 Best Upmetrics Alternatives for Your Business Planning [2024] - August 30, 2024
