Unless you’re planning to use Salesforce in its out-of-the-box (OOTB) format, you’ll need to customize it to fit your unique business needs and sales processes.
Some customization is fairly simple and doesn’t require much (or any) testing, such as introducing new field values to Picklist Value Sets or changing minor items on an object’s page layout or Lightning Page.
But if you’re introducing custom development of any kind, bugs are likely (if not almost a certainty). To ensure these bugs are detected (and resolved) before changes are deployed to your live Salesforce instance, thorough testing is critical for success.
UAT (user-acceptance testing) is an imperative type of testing that seeks to validate your custom solution and verify that it meets expectations for all impacted users.
In this post, we’ll give you a quick rundown of Salesforce UAT, including best practices and workflows.
What is Salesforce User-Acceptance Testing (UAT)?
As described above, UAT is a method by which users test whether a custom development solution meets performance standards and business requirements before that solution is deployed to a production instance.
Depending on the type of Salesforce user acceptance testing being carried out, it may be conducted by developers, administrators, quality assurance professionals, and/or business users (otherwise known as end users).
UAT generally occurs in a dedicated testing environment (a Salesforce sandbox, or multiple sandboxes). The solution is tested on numerous test scenarios on a variety of users and levels of access to demonstrate that it works as expected in all situations.
User acceptance testing is most often performed late in the development process, once the solution has been fully built out. If your Salesforce project is being managed through a methodology like Agile or Scrum, your organization may experience repeated bouts of UAT as the project enters and exits different sprints or phases of the project.
Note: Check out our article on project management methodologies for Salesforce projects here.
Once testing begins, any detected issues or bugs are logged and addressed, and then—you guessed it—tested once again under the same scenarios. When all identified issues have been resolved, the custom solution is ready to be deployed from your testing environment to your production environment.
Successful production deployments are dependent upon UAT, and no custom Salesforce CRM solution should be implemented without it.
Salesforce UAT Workflow
While UAT processes can vary, it is always a multi-step process that should include the following steps.
Planning
Stakeholders and all involved parties define the project’s intended outcome, technical specifications, and deliverables. If there are key requirements (such as certain profiles lacking access to new applications, fields, or custom objects), this should be noted.
Before test cases can be created (see the next step), the organization will need to group together to create User Stories and acceptance criteria, to inform the development and testing team of how they envision the end product and experience.
User Stories are informal explanations of how a custom solution should work from an end user’s perspective, demonstrating how the changes or deliverables will provide value. Because User Stories focus on the end user’s experience, they make it easier for the development team to determine how to best serve them. To create User Stories, start with a simple one-sentence format, such as:
- As this type of user,
- I want to… (or conversely, I do not want to…)
- So that…
Here’s a very simple example from a recent Parquet project that required the creation of new custom profiles.
- As a Rev Ops user, I want to see campaign influence on opportunity records so that I can see how the marketing team’s initiatives are influencing our bottom line.
- However, as a Rev Ops user, I do not want the ability to create or edit campaigns so that the marketing team can fully own this object in Salesforce.
This stage should also include the designation and understanding of all tools involved, as well as those that will be tasked with the Salesforce application UAT process once the project is ready for it.
Coordinate with your project manager to ensure everything is properly and thoroughly documented.
Preparation of Test Cases
Based on the business requirements, user stories, and deliverables outlined in the planning phase, test scenarios will be created with multiple users, profiles, outcomes, and possibilities in mind. Input should be requested from stakeholders and actual end users alike, provided they are familiar with the overall goals of the project.
Bear in mind that a software development team knows to focus on functional testing but likely lacks the same extensive domain knowledge as the rest of your team, making the preparation of test cases and scenarios critical for UAT success.
Preparation of Test Environment
The best Salesforce testing strategy in the world won’t work without the right testing environment.
Remember that not all sandboxes are created equal; the best type of sandbox for user acceptance testing (and development, for that matter) is a recently-refreshed full or partial replication of your production instance.
Finally, if the business needs call for it, consider creating multiple testing environments. Many development cycles involve multiple developers working in parallel on separate tasks, and they may inadvertently write over one another’s work if working within the same sandbox.
As with most things in Salesforce, your ability to create sandboxes is dependent upon licenses, so it’s worth checking into what you have available before you develop a plan for a Salesforce UAT instance.
Testing
Once the development cycle has concluded, your project is ready for user acceptance testing. Remember those test cases? We’re finally ready for them.
UAT testers will run through these scenarios to see if any glitches or issues pop up, logging them as they go. Once the first round of issues has been logged, the development team will get to work on resolving them… and then the testing process can resume—or repeat—until all testers are satisfied with the solution and its deliverables.
Outcome Analysis
Provided your user-acceptance-testing yielded positive results, the outcome analysis should be simple: stakeholders will agree that the solution is compatible with business requirements and real-world usage.
At this stage, your new custom solution will be deployed to your production environment. Black Box and Beta Testing (more on this later) will sometimes be conducted after this step by end users in your live environment.
It’s unlikely, but there are times when a Salesforce development project is deemed incompatible, and therefore must be scrapped and re-evaluated or re-engineered. If your final phase was indeed unsuccessful, you should archive, refresh, or delete your UAT sandbox(es) so that no future changes are made to an instance that didn’t survive Salesforce QA.
Types of User-Acceptance Testing in Salesforce
Before you deploy those new changes, it’s essential that your team has fully evaluated its utility and usability. Here are some common acceptance test types that your team might use.
Alpha Testing
Alpha Testing will be conducted entirely within the designated testing environment. The primary goal in this phase of the Salesforce UAT process is to evaluate the quality of the solution and focuses on core functionality, using both White and Black Box testing methods (explained in the next sections). Critical issues and bugs are addressed immediately during Alpha Testing.
Beta Testing
This type of Salesforce UAT happens once Alpha Testing has concluded, and can be performed in both testing or production environments. There is still a functional testing focus, but the primary goal of Beta Testing is to verify reliability, security, and user satisfaction and adoption. Feedback from end users will be considered, resulting in possible changes to the solution.
Unlike Alpha Testing, Beta Testing can be conducted by users in all roles, from developers to business users. Beta testing mainly involves the Black Box testing method.
White Box Testing
White Box Testing is a technique in which the solution’s design, coding, and internal structure are tested to verify input-output flow and ultimately improve usability, security, and design or interface.
Because white box testing focuses on the inner workings of the Salesforce application, this is carried out by developers and administrators familiar with the custom solution and its mechanics.
Black Box Testing
Black Box testing is the counterpart of White Box testing, involving test cases and business requirements being presented to testers unfamiliar with the internal code structure.
The “black box” in Black Box Testing symbolizes not being able to see the mechanics or inner workings of the custom solution so that only the end-user experience is tested.
Successful Salesforce UAT Best Practices
These practices can be implemented in custom Salesforce projects of all sizes and levels of complexity to make the user-acceptance-testing process more efficient.
Train your UAT testers: Testing should be conducted in a way that enables the tester to understand its purpose. UAT quality can be improved by providing clear guidance and a description of the tasks that your testers should perform. Consistency can also be achieved by providing guidelines on how to record feedback.
Additionally, ensure all testers understand the basics of Salesforce sandboxes (UAT testing is often a foreign concept to end or business users, and therefore requires more hand-holding). Some users, for example, might need to be trained on something as simple as understanding when they’re in a Salesforce sandbox, versus the production environment.
Be flexible: Most test cases involve multiple steps and considerations, but testers should not be discouraged from slightly straying from the path. To discover problems that developers didn’t anticipate, testers should use the application in the same way they would normally.
Keep clear communication: UAT is an ongoing process and success relies on constant and clear communication. Effective interaction is key to reducing misunderstandings and improving overall UAT quality and outcome.
Use UAT tools: UAT testing can be painful. It is strongly recommended that you leverage tools that seek to simplify and improve efficiency.
Popular Salesforce UAT Testing Tools
There are many tools related to the UAT testing process on the market. If you’re using any of them, you’re on the right track. We’ve included a few types of popular tools below.
Issue-Tracking Tools
Atlassian Jira is easily the most recognizable (and common) contender in this area, but it’s not the only option. Jira—and tools like it—are built to manage projects and track issues, facilitate communication among different parties, create reports and assign tasks to developers, testers, or anyone else involved. We beg you—don’t resort to spreadsheets here!
Code Repository Tools
A code repository is an archive of the code being actively worked on. Popular options include GitHub and Bitbucket. You can also keep documentation, notes, web pages, and other items in your code repository.
Complicated development projects really necessitate the usage of a code repository—or certainly any Salesforce development projects that require hard code.
SOP and Testing Guide Creation Tools
We use Scribe to create step-by-step testing guides and tutorials for users quickly and easily (sometimes in seconds). These types of guides are invaluable for testers as they provide a walk-through that’s easy to follow, and prevent the need for repetitive meetings and testing demonstrations.
Scribe (and most tools like it) even allow you to embed the guides in your internal help center or knowledge base, making it that much simpler to direct your testing team to the right resource hub for their needs.
Test Management Tools
Tools like Testim seek to modernize test automation, whereas tools like Panaya attempt to make it easier to keep track of test environment changes.
Depending on your end goals and the complexity of your solution, the usage of a test management tool may be beneficial.
Salesforce Adoption Dashboards
While not technically a separate tool, using adoption dashboards to monitor org usage after deployment can be incredibly helpful for Administrators.
The components and source reports used in this type of dashboard will be dependent upon the new features or solutions created, so be sure to consult with your Salesforce consultant about how to go about this process.
Conclusion
Salesforce is the most widely used CRM to help companies manage their day-to-day operations. It is a comprehensive solution that grants you endless customization options—but the successful deployment of most customization requires thorough testing.
Struggling with your Salesforce project’s UAT process? Reach out and let us know.
