Why UAT Fails Even When it Appears Successful
In many UAT cycles, all test scripts are marked as passing, only for dozens of incidents to emerge two weeks after go-live. This isn't a paradox. It's a direct outcome of testing designed around screens.
Screen-based testing asks, "Can a record be created?" Process-based testing asks, "Can an agent receive an inquiry, identify the customer exists under a different name, check their eligibility in the core system, open a case, escalate it to another party, and close it—when the customer exists twice in the system?" The second scenario uncovers what the first misses.
This guide presents a UAT structure that addresses the second question. Its connection to other project phases is detailed in the Salesforce Implementation Guide.
What Must Be Ready Before Starting
- A stable environment that doesn't receive deployments mid-cycle, except for approved blocker fixes.
- Test data of similar scope and complexity to production.
- Users with actual permissions—not Admin for everyone. Half of all permission issues are only discovered when the tester has the correct profile.
- Defined acceptance criteria for each core process.
- A single reporting mechanism for issues, with minimal mandatory fields.
The item most often skipped is the third, and it's the one that generates the most embarrassing incidents on go-live day.
How to Build a Test Script That Finds Problems
A good test script starts with a persona and an initial state, not a click. A working structure:
- Who — precise role and permission.
- Initial State — what information exists in the system before the script begins.
- What Happens — the business event that triggers the process.
- What the Tester Does — at a business action level, not a click level.
- Expected Outcome — including what happened in other systems.
- What Should Not Happen — the record is not exposed to unauthorized users, the alert is not sent twice.
The sixth point distinguishes between a checklist and professional testing.
Six Scenario Families That Must Be Included
| Family | Scenario Example | What it Uncovers |
|---|---|---|
| Happy Path | Complete end-to-end process | Is the process even feasible |
| Business Exception | Cancellation, refund, return to previous stage | Logic built only in one direction |
| Problematic Data | Duplicate customer, name in Hebrew and English, blank field | Insufficient mapping and cleansing |
| Permissions | User attempts to access a record from another unit | Gaps in the exposure model |
| Integration Failure | Target system is unavailable | Error handling, loops, duplication |
| Volume | Batch operation on a large number of records | Performance and automation limitations |
The absence of an entire family from this list is a sign that the testing will provide false confidence.
Severity Classification — The Key to Managing the Cycle
Without an agreed-upon classification, every defect seems urgent, and the decision to go live turns into an argument. A four-level model is sufficient:
| Level | Definition | Impact on Go-Live |
|---|---|---|
| Blocker | Core process cannot be completed, no workaround | Blocks go-live |
| Severe | Process is possible with a heavy workaround or incorrect data is saved | Blocks go-live unless explicitly approved |
| Medium | Significant inconvenience, reasonable workaround | Does not block go-live, enters remediation plan |
| Low | Wording, field order, enhancement | Collected for the next release |
The important rule: the process owner, along with the technical team, determines the classification, not the person who reported the issue.
Go-Live Criteria
These are articulated before the start of the cycle, not at its end:
- Zero open blocker defects.
- All severe defects either closed or approved in writing with a workaround and fix timeline.
- All core processes run in a second cycle without new failures.
- Process owners have provided written approval.
- A tested rollback plan exists, not just a written one.
Illustrative Example: Pension Fund
This scenario is hypothetical and illustrative. A pension fund tested its member inquiry handling process. The first UAT cycle passed almost completely. The team noticed that all testers used a single, extended profile because the assignment of precise profiles was delayed.
In the second cycle, with the actual profiles, eleven defects were found: agents couldn't see records of members who had transferred between schemes, an approval button for an exception appeared for unauthorized users, and a workload report returned partial results for team leads. None of these defects were related to the functionality tested in the first cycle—all were in the exposure model.
The practical conclusion adopted there: do not start a UAT cycle before all participants are on the profile they will use in production.
Management Mistakes That Increase Cycle Costs
- Deploying versions mid-cycle, which invalidates already performed tests.
- Testers reporting via WhatsApp and email concurrently with the tracking system.
- Scripts written at a click level, turning every UI change into a documentation update.
- Shortening the second cycle due to schedule pressure—this is the cycle that uncovers regressions.
These patterns appear alongside other failures in the Common CRM Implementation Mistakes Guide, and responsibility for each is defined in the Salesforce Project Team Roles Guide.
When Replacing an Existing System
In a replacement project, UAT gains a second role: comparison. The same ten scenarios are executed in both systems, and results are compared field by field. This is the most effective tool to uncover mapping discrepancies before they become trust gaps. The sequence of operations in such a transition is detailed in the Salesforce CRM Replacement Guide.
What Remains After the Cycle
UAT scripts are not a one-time document. They form the basis for regression tests in every future release, and they are the best source for training materials—because they are written in process language, not system language. Storing them in a reproducible format is the cheapest investment one can make for the coming year.