Automation V3: Provar Naming Standards

Provar has excellent flexibility for creating dynamic tests with a low maintenance overhead. We recommend the following naming standards to help you maximize your Provar implementation.

For brevity, the scope of this document is limited to the following:

Test folders
Test case names
Parameters, variables, and return values
Step names

Test case folders

Folders help you divide your test cases and work in a modular fashion. They also make it much easier to create test suites using Test Plans.

Folders also have a special property of allowing you to define local startup and teardown tests in a folder and to set execution scope based on a folder.

Use a consistent naming strategy when creating your folders so it’s clear to your users where to store their test cases. At the same time, keep in mind that the folder name will appear in the execution results, so it’s a good idea to keep it short.

Some suggested examples (feel free to mix and match) include:

Strategy One: Create modules based on the end-to-end business process being tested. For example, you could have folders for Lead to Cash, Ticket to Resolve, and more functional areas broken down as Lead Management, Account Management, Case Management, and Customer Self Serve.

Strategy Two: Create modules based on the application and/or objects being tested. Use a shared folder for reusable steps that can be used across multiple applications and test scenarios.

Strategy Three: Use a numbering prefix if you want strict control over the order in which folders appear. Using sub-numbers can be useful if you have hundreds of tests, but it indicates you may want to re-think your test folder design to have fewer tests per folder.

Strategy Four: If you’re migrating from Classic to Lightning, you may want to organize your top-level folders accordingly. Although Provar supports tests across both Classic and Lightning, your Salesforce team should use Lightning features such as Flexipages to optimize the UI. You may find top-level folders for Classic, Lightning, and both useful until you finish your migration. You can switch off the Classic tests when you’re done, so you don’t need to maintain them.

Strategy Five: Create a Utility folder for storing your callable tests that can be used anywhere. This could be your Slack or Jira integration test, for example. These should be red flags if someone changes them, as they could impact multiple tests and require a full regression test plan.

Top tips to follow for test case folders

Define a folder structure that is sensible to your stakeholders who will review the test results. Make it easy for them to find the information they care about and understand the impact of test failures on their department, business unit, or process.

Use standard abbreviations to shorten object names, such as Acc for Account and Opp for Opportunities.
Check out and adopt naming standards already used by your Salesforce project team since this can help avoid rework and make it easier to understand test results.
Consider creating your folders using your preferred local OS file manager. This is often faster and easier to restructure and rename
Remember to check your folders into your Version Control System (VCS)!

Top mistakes to avoid for test case folders

Do not use more than three levels of subfolders under the tests folder. This is hard to navigate and makes life more difficult for your team!

Avoid renaming or reordering folders after you’ve connected your VCS; it can cause problems if you haven’t removed the old folders first.
Avoid special characters in your folder names since they can make your tests OS-dependent

Test case names

Test case names are essential in Provar since they control the default order in which test cases appear in the Navigator. If you would like to structure your test cases so they are easy to find within a parent folder, consider the following alternate options:

Strategy One: Prefix your test case names with a meaningful external key. This could be:

A Jira Issue number for the Epic they relate to
A Zephyr or Testrail key from which the test plan was imported

Strategy Two: Use a number sequence to set your test case sequence. To avoid renumbering later, consider using multiples of 5 or 10 in your test case names.

Strategy Three: Use short, meaningful descriptions to describe the user flow under test.

Top tips to follow for test case names

Use meaningful shorthand names (e.g., Opp not O for Opportunity)

Use spaces, dashes, underscores, and CamelCase to make names readable
Be consistent in the use of underscores, prefixes, and number prefixes
If you need certain records populated before running your tests, put them in a Startup test and name it accordingly, such as 00 Populate Accounts & Contacts for Sales Tests. Remember that Salesforce API tests are the fastest way to build and execute these.

Top mistakes to avoid for test case names

Do not make test case names so short they’re hard to understand. 01SaAcEd may be very clear, but 01 Sales Acc Edit is more readable for everyone else!

Denote startup and teardown tests by name. Provar does this for you with different icons.
Do not rename your test cases just to reorder their execution. A better folder structure can achieve the same thing.

Test case parameters & variables

Content Assist is a valuable tool for accessing values you’ve already defined as part of your test design. Like programming languages, Provar does allow you to redefine a variable that has already been declared. A variable or result can be scoped to the following options:

Test Run Global across all tests during execution
Test Folder Visible across all tests in the same folder
Test Case (default) Visible for the rest of the steps in the test
Group Step Visible to steps within the same parent Group step
Test Step Not visible after the step executes

While powerful, this can have unforeseen consequences during execution. Consider using the following prefixes and examples to make these very clear to your team members:

*Provar does not use any prefixes by default.

Top tips to follow for test case parameters & variables

If you expect to re-use or access a variable or result, give it a meaningful name

Use CamelCase for your parameter and variable names
Be consistent with variable names across your tests when they mean the same thing

Top mistakes to avoid for test case parameters & variables

Be careful when redefining the exact variable multiple times in the same test scope to mean different things semantically (e.g., use lvCaseId and lvAccountId rather than lvObjectId and reuse for both an Account id on one step and Case id on another).

Test step names

Provar names test steps automatically to make them easy to read and understand. However, you can rename any test step to improve clarity or to adhere to a specific labeling convention. One exception is when it comes to UI Assert (because of the complex scenario of multiple value asserts in a single step). The following tips should be helpful.

Top tips to follow for test step names

Consider editing the step name if you edit what the step is doing to make it a data-driven step.

Use either BDD or Group steps to document some steps to comment on the steps being performed and why
Enter descriptions that explain to a non-QA user what’s being tested.

Top mistakes to avoid for test step names

Do not leave UI Assert statements as UI Assert; add something meaningful like UI Assert: Check total price including discounts. Renaming UI Assert steps is even easier now that you can do this in Test Builder.

Documentation library

Documentation

Looking for something in particular?