Provar naming standards
Provar has a great flexibility for creating dynamic tests with a low maintenance overhead. We recommend the following naming standards to help you make the most of 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, Customer Self Serve.
Strategy Two: Create modules based on the application and/or objects being tested. Use a common folder for re-usable 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 indicates you may want to re-think your test folder design so that you 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 really be taking advantage of 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 then 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.
- Try to use common abbreviations to shorten object names such as Acc for Account and Opp for Opportunities
- Check out and adopt naming standards already in use 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 important 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 use of underscores, prefixes and number prefixes
- If you need certain records populated prior to 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 to you 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 that you’ve defined already 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 same 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 actually doing to make it a data-driven step
- Use either BDD or Group steps to document a number of 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 includes discounts. Renaming UI Assert steps is even easier now that you can do this in Test Builder.
- General information
- Licensing Provar
- Provar trial guide and extensions
- Using Provar
- API testing
- Behavior-driven development
- Creating and importing projects
- Creating test cases
- Debugging tests
- Defining a namespace prefix on a connection
- Defining proxy settings
- Environment management
- Exporting test cases
- Exporting test projects
- Managing test steps
- Namespace org testing
- Provar desktop
- Provar Test Builder
- Refresh and Recompile
- Reload Org Cache
- Running tests
- Searching Provar with find usages
- Secrets management and encryption
- Setup and teardown test cases
- Tags and Service Level Agreements (SLAs)
- Test cycles
- Test plans
- Testing browser options
- Tooltip testing
- Using the Test Palette
- Test Palette introduction
- Control test steps
- List compare
- Read test step
- String test steps
- UI Test Steps
- Using custom APIs
- Callable tests
- Data-driven testing
- Page objects
- Applications testing
- Database testing
- Document testing
- Email testing
- Mobile testing
- OrchestraCMS Testing
- Salesforce CPQ testing
- ServiceMax testing
- Skuid testing
- Vlocity testing
- Webservices testing
- Introduction to test scheduling
- Apache Ant
- Configuration for sending emails via the Provar Command Line Interface (CLI)
- Continuous integration
- Azure DevOps
- Running a Provar CI task in Azure DevOps
- Configuring the Provar secrets password in Microsoft Azure Pipelines
- Parallel execution in Microsoft Azure Pipelines using multiple build.xml files
- Parallel execution in Microsoft Azure Pipelines using targets
- Parallel execution in Microsoft Azure Pipelines using Test Plans
- Bitbucket Pipelines
- Circle CI
- GitLab CI
- Travis CI
- Parallel Execution
- Running Provar on Linux
- Salesforce DX
- Team foundation server
- Version control
- Zephyr Cloud and Server (Beta)
- Salesforce testing
- Adding a Salesforce connection
- Assert Page Error Messages on Add/Edit Product
- Internationalization support
- List and table testing
- Salesforce critical updates
- Salesforce Lightning Testing
- Salesforce Lightning Web Component (LWC) locator support
- Service Cloud console testing
- Visualforce Testing
- Testing best practices
- Configurations and permissions
- Error messages
- Licensing, installation and firewalls
- Test Builder and test cases
- Release notes