Documentation

Looking for something in particular?

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.

.

Review Provar on G2
Documentation library

Trying to raise a case with our support team?

We use cookies to better understand how our website is used so we can tailor content for you. For more information about the different cookies we use please take a look at our Privacy Policy.

Scroll to Top