Salesforce UAT: a practical guide

When you need a UAT in Salesforce

A user acceptance test answers one question: can the business do its work in this version of Salesforce? The people who do the work test it, in their own words, before it reaches production. You need one at these moments.

• A go-live. The first Sales Cloud or Service Cloud, or a move from another CRM.
• A new cloud or a big change. Adding Service Cloud next to Sales Cloud, CPQ, a new integration with the ERP, or a new way of routing cases.
• Each Salesforce release. Salesforce has three releases a year: Spring, Summer and Winter. The Winter release comes in the autumn and carries the number of the next year. Each release can change how your org works, even if you changed nothing yourself.
• The sandbox preview. Sandboxes on a preview instance get the new release some weeks before production. That is your window to test. Before each release, Salesforce publishes which instances are in the preview and what to do to keep a sandbox there. Check it in time, because a refresh can move a sandbox in or out of the preview.

A go-live needs a full UAT. A release needs a shorter regression test of the processes that matter most. More on that under After the go-live.

The sandbox

Never test in production. Salesforce has four types of sandbox. Two of them are fit for a UAT.

Plan the refresh

A refresh replaces everything in the sandbox with a new copy of production. Every sandbox type has a minimum time between refreshes, and a Full sandbox has the longest one. So plan it:

• Refresh before the UAT, never during it. Check when the sandbox can be refreshed next.
• Deploy the release to the sandbox after the refresh. Work that only existed in the sandbox is gone.
• Do the steps after a refresh: point integrations and named credentials to test systems, not to production, and switch off scheduled jobs that should not run.
• Check the email deliverability. A new or refreshed sandbox sends system email only. Web-to-lead replies, approvals and case emails need more, but a Full sandbox holds the real email addresses of your contacts. Use test addresses before you open it up.

Test data

Testers lose hours when the data is not ready. Prepare it before the first test day:

• Accounts and contacts for each type of customer you test, with the right owner, region and record type.
• Products and price books. A product needs a price in the standard price book before it can be in another price book. Check that the price books of each sales team are active.
• Open records to work on: opportunities in different stages, open cases, and cases close to a milestone if you test entitlements.
• No real personal data where you can avoid it. A Full sandbox copies everything, so mask or anonymise what testers do not need to see.

Users per profile and permission set

A UAT proves that each role can do its work, and only its work. Create a test user for every combination of profile, role and permission sets you test, such as a sales rep, a sales manager and a service agent. Each tester gets their own user, so two people never work in the same user at once.

After a refresh, Salesforce adds the sandbox name to every username and .invalid to every user's email address. Set the email of each test user to an address the tester reads, or password resets and approval emails go nowhere.

Log in as lets an admin see Salesforce through the eyes of another user. It is a good way to look at a problem a tester reports. For the test itself, testers use their own test user: that is how you know the profile and the permission sets are right.

What to tell testers about the sandbox

• The address of the sandbox. It has the name of the sandbox in it, or they sign in through test.salesforce.com. The normal login page of Salesforce opens production.
• Their username, which ends with the name of the sandbox, and how they get their password.
• That the data is test data: nothing they do reaches a real customer, and nothing they see is current.
• Who to call when they cannot sign in, before they lose a morning.

In UAT StudioEach tester gets a Test role and a Test account, shown at the top of their tests as Log in as …. The Notes for testers hold the sandbox address, test mailboxes and who to call.

Test cases from user stories and processes

Start from the processes of the business, not from the objects in Salesforce. Two processes cover most of a Salesforce UAT:

• Lead to cash. A lead comes in through web-to-lead, is assigned and converted. The opportunity gets products from the price book, a quote is made and approved, the deal is won, and the order or contract goes to the next team or system.
• Case management. A case comes in through email-to-case or the portal, is routed to the right queue or agent, follows its entitlement and milestones, is solved with a knowledge article, escalated when needed, and closed.

Cut each process into test cases of one business scenario each, such as Convert a lead with an existing account. Then check that every user story in scope has at least one test case.

Steps business testers understand

Write each step as an action and an expected result, in the words of the tester. Add test data where it matters. A tester should never have to guess whether a step passed.

Priority and risk

Not every test case is equally important. Mark each one Must, Should or Could: Must is what has to work on day one, such as creating a quote or routing a case. Add the risk: what it costs when this goes wrong after go-live. Testers start with Must and high risk, so the important tests are done even when time runs out.

Add the unhappy paths too: a required field left empty, a discount above the limit, a user who should not see a record.

In UAT StudioImport your test cases from Excel with the columns Priority and Risk, or start from the Salesforce scripts in the template library, an add-on to every paid plan. Testers see their Must test cases first.

Testers

Choose people who do the work every day: sales reps, service agents, and their managers for approvals, forecasts and reports. Take testers from every team and country that uses Salesforce, because their processes and price books differ.

How much time

Ask for the time per tester, not per team, and get it agreed with their manager. Plan the scripts so that each tester knows how much there is to do. Keep time for retests after the fixes. Testers who are still taking calls or visiting customers will not finish.

A kick-off

Start with a short kick-off: why their test matters, how to sign in to the sandbox, how to record a result and how to log an issue. Let every tester sign in once during the kick-off. Most problems with users and passwords show up there, not on the test day.

One test day or a week

• One test day, in one room or one call, gives focus and quick answers. It suits a small scope and testers who are hard to free for longer.
• Spread over a week, in blocks of a few hours, leaves room for fixes and retests between the blocks. It suits a go-live with many processes.

Either way, fix a time for the triage every day.

During the UAT

Logging issues

A good issue can be fixed without a meeting. Ask testers for:

• The step, what they expected and what happened instead.
• A screenshot of the page.
• The link to the record. It is in the address bar of the browser and takes the developer straight to the opportunity or case where it went wrong.
• The user they tested with, so the team knows which profile and permission sets were used.

In UAT StudioThe browser extension for Chrome and Edge shows the tests in a side panel next to Salesforce. A failed step takes the screenshot, the link to the record and the error messages of the page along. An issue shows the record as a link, sandbox included.

Triage

Go through the new issues every day, with the business and the Salesforce team together. Give each one a severity and someone who fixes it, and decide:

• Fix: a real problem, fixed in this release.
• Reject: Salesforce works as designed, or the test was wrong.
• Change request: a wish, not a defect. It goes to the backlog, not into this release.

Retest

When a fix is deployed to the sandbox, the tester who found the issue tests the step again. Write down which build each retest was done on. After a large fix, test the processes around it again too.

Daily status

Send the steering committee a short status every day: progress against the plan, open issues by severity, and what blocks. Keep it to facts. No surprises at the go/no-go meeting.

In UAT StudioThe triage runs on a shared screen with Fix, Reject and Change request. Ready for retest emails the retester. A daily overview by email, or in Microsoft Teams, shows the results and the issues of the day before.

Sign-off and go/no-go

The UAT ends with a decision by the business. Agree the exit criteria before the first test day, so nobody argues about them at the end:

• No Critical issue is open.
• Every Must test case has passed.
• Every open High issue has a workaround or a date for the fix that the business accepts.
• Every test case in scope has a result.

Who signs

The owner of each process signs off, such as the sales director for lead to cash and the head of customer service for case management. They choose: accepted, accepted with conditions, or rejected. Write down every condition, with who does it and by when. The steering committee then decides on the go-live.

What goes into the report

• What was in scope, and what was not tested.
• The results per process or team, and per priority.
• The sandbox, release and build that were tested.
• The open issues by severity, with the decision on each one.
• The sign-offs, with their conditions, and the known risks for the first weeks.

In UAT StudioSign-off per group: Accepted, Accepted with conditions or Rejected. By default, nobody can accept while a Critical issue is open. The go/no-go report is ready as a PDF or as slides when the last result is in.

A regression round for each Salesforce release

After the go-live, the releases keep coming: three a year. Each one can change a page, a flow or a permission. Your UAT test cases are the best regression test you have, because they describe exactly what the business accepted.

• Keep the test cases after the go-live, with their steps, test data and expected results.
• Read the release notes of the coming release, and check which features are switched on for you automatically.
• Check that your UAT sandbox is in the sandbox preview, and plan the round in the preview window.
• Test the Must test cases again, and Should if there is time, with a few testers from the business.
• Log issues as in the UAT, and fix them before the release reaches production.

In UAT StudioChoose Salesforce as the CRM of the project. The projects page then shows the coming Salesforce releases, with the date of the sandbox preview, the date of production and the release notes. Start a regression round copies the test cases you choose: Must and Should, Only Must or All test cases in scope.

Free to use

For everything to arrange before, during and after the UAT, see the UAT checklist for a CRM go-live, also as a free Excel file. For what UAT Studio does for a Salesforce UAT, see Salesforce UAT.

Salesforce, Sales Cloud and Service Cloud are trademarks of Salesforce, Inc. UAT Studio is not affiliated with or endorsed by Salesforce.