UAT Test Plan Template for Salesforce
Plan user acceptance testing that business users can actually run: what to put in each section, a test case format with example rows, and clear sign-off rules.
User acceptance testing is where the business confirms that what was built does the job it was meant to do. It is not a second round of developer testing, and it is not a demo. A good UAT plan tells testers what to test, with what data, how to record results, and what has to be true before anyone signs off.
Use the sections below as your plan. Most teams keep the plan as a short document and the test cases in a spreadsheet or test management tool.
What the plan covers
Scope
Which user stories, processes and roles are in UAT, and which are not. Tie each item back to an agreed requirement.
Entry criteria
What must be true before UAT starts: system testing passed, data loaded, users set up, known defects listed.
Test data
Realistic records testers can use without touching production data or real personal information.
Test cases
Business scenarios written in the users' language, each with steps and an expected result.
Defects
How issues are logged, rated for severity, fixed and retested.
Exit and sign-off
The conditions for acceptance and who signs.
Environment and access
Name the sandbox used for UAT. A full sandbox gives testers realistic configuration and volumes, and a partial copy sandbox gives a representative sample of data; check which sandbox types your licence includes. Freeze deployments into the UAT sandbox during test cycles, except agreed fixes, and record each fix deployed so testers know what to retest.
Testers should log in as users with the same profile, permission sets and role as the people they represent. Testing as a system administrator hides sharing and permission problems, which are among the most common defects found after go-live.
Test data
Prepare data that covers the scenarios rather than relying on whatever is in the sandbox. If you copy production data into a sandbox, mask or remove personal data according to your data handling policy. Use example.com addresses for any email testing, and make sure sandbox email deliverability settings are set deliberately so no real customer receives a test message.
Test case format with example rows
| ID | Scenario and role | Steps | Expected result | Status |
|---|---|---|---|---|
| UAT-01 | Sales rep converts a qualified lead | Open lead, click Convert, choose existing account | Contact and opportunity created on existing account; lead source carried over | Not run |
| UAT-02 | Service agent closes a case | Add resolution, set status Closed | Customer notification sent; case closed date set | Not run |
| UAT-03 | Marketing user builds a segment | Filter contacts by region and consent | Only opted-in contacts in region included | Not run |
| UAT-04 | Sales manager reviews pipeline | Open regional dashboard | Totals match agreed test data set | Not run |
| UAT-05 | Rep without access opens a restricted record | Search for record owned by another region | Record not visible | Not run |
Defect severity definitions
| Severity | Meaning | Release impact |
|---|---|---|
| Critical | Core process cannot be completed and there is no workaround, or data is lost or exposed | Blocks sign-off |
| High | Core process works only with a difficult workaround | Blocks sign-off unless the business accepts the workaround in writing |
| Medium | Non-core function wrong or awkward; workaround exists | Can go live with an agreed fix date |
| Low | Cosmetic or wording issue | Fix when convenient |
Running the test cycles
- 01
Brief the testers
Walk through the plan, the test case format and how to log defects. Show them one case end to end.
- 02
Cycle one
Testers run all cases and log results and defects. The project team triages defects daily.
- 03
Fix and retest
Agreed fixes are deployed to the UAT sandbox in batches; testers retest affected cases and run a small regression set.
- 04
Cycle two
Rerun failed and affected cases, plus any cases touched by fixes.
- 05
Sign-off meeting
Review results against exit criteria, agree any accepted known issues, and record approval by the named business owners.
Questions we hear
Who should write UAT test cases?
How is UAT different from system testing?
Should marketing journeys go through UAT?
What if UAT finds a missed requirement?
Exit criteria
Typical exit criteria are: all planned cases executed, no open critical or high defects, medium defects have agreed fix dates, and each business area owner has signed. Write yours down before testing starts, and keep the signed results with the release record.
Related reading
Need a structured UAT?
We can prepare your UAT plan, test cases and test data, and coordinate testers through to sign-off.
