To enhance maintainability, scalability, consistency, and clarity across the organization’s Test Automation operation, Panaya recommends standardizing a naming convention for assets used in the account. These include diverse types such as test scripts, reusable components, parameters, etc. But the goal is the same: ensuring alignment across all relevant users. The following are a few guidelines that combine general industry best practices as well as Panaya specifics to assist you in building a robust and well-structured test automation library.
General Principles
Consistency
Use consistent naming conventions across all scripts, datasets, and components.Clarity
Names should be descriptive enough for anyone to understand the purpose without additional explanation.Simplicity
Avoid overly long names; use abbreviations sparingly.Avoid Special Characters
Use underscores (_) or camelCase instead of spaces or special characters.Prefixing and Suffixing
Use prefixes or suffixes to denote specific types of elements (e.g., ds_ for datasets, output parameters, etc.).Panaya recommends managing automated tests and reusable components in a dedicated “catalog” system/project. Tests can be imported (cloned), and reusable components can be utilized. This minimizes redundancy and overflowing the account with assets, making tracking harder as the project scales.
We suggest managing the assets in a hierarchy resembling the following:
Hierarchical Structure
Project Cycles by Functional Area (Type of Testing)
The cycle is the top level, could be named by:
Testing Phase: Cycle_UAT, Cycle_Regression.
System/Release: Cycle_2024Q1_Release.
Naming considerations for distinct assets
Naming Test Scripts
Include a prefix indicating the type of test:
st_ (Smoke Test).
rt_ (Regression Test).
Include:
Functional Area: tc_OrderManagement_CreateOrder.
Scenario/Detail: tc_OrderManagement_InvalidOrderData.
Example: rt_Billing_ProcessInvoice_InvalidPaymentMethod.
Naming Data Sets
Use the prefix ds_.
Include:
Test Cycle: ds_UAT.
Purpose: ds_ValidCustomerData.
Number: ds1_ValidCustomerData
Example: ds1_Billing_ValidInvoiceData.
Naming Parameters
Use the prefix param_ and include the parameter “type” (Input/Output/Internal)
Include the context in the name:
inputParam_CustomerID.
outputParam_OrderDate.
Group common parameters by scope:
Global: param_Global_BaseURL.
Test-Specific: param_Testcase_001.
Reusable Components
Use a prefix to indicate the type of component:
rc_ (Reusable Component).
Include:
System: rc_SAP.
Purpose: rc_SAP_Login.
Indicate versions if applicable:
rc_SAP_Login_v1.
Example: rc_Salesforce_CreateLead.
Additional Best Practices
Documentation: Maintain a glossary or guide for all naming conventions.
Environment-Specific Parameters: Differentiate environment-specific variables:
env_DEV_URL.
env_PROD_URL.
Align to the organization: Communicate and collaborate. Ensure that the above implementation is shared and adheres to your company’s policy, culture, and guidelines.