10.1 UAT Strategy, Test Planning & Entry/Exit Criteria

10.1 UAT Strategy, Test Planning & Entry/Exit Criteria

Quick Answer: User Acceptance Testing (UAT) is the formal verification phase where designated business stakeholders and frontline end users validate that a configured Salesforce solution supports actual business operations and fulfills agreed-upon requirements. Unlike developer unit tests (Apex code coverage) or QA/SIT (technical specification verification), UAT answers the strategic question: "Does this system actually solve our business problems and allow us to execute our daily operations effectively?" To protect business resources, UAT governance relies on strict Entry Criteria (e.g., 100% QA regression passed, zero Severity 1/2 defects, seeded sandbox, provisioned permissions) and Exit Criteria (100% scenarios executed, >= 95% pass rate, zero critical defects, and signed acceptance documentation).

In enterprise Salesforce rollouts, technology is only as valuable as the business outcomes it enables. A development team can deploy flawless Apex classes, highly optimized Flow automations, and elegant Lightning Web Components that achieve 100% technical test coverage, yet the rollout can still fail catastrophically if the solution does not align with how business users actually sell, service customers, or process transactions.

User Acceptance Testing (UAT) serves as the ultimate quality gate before deployment to Production. For a Salesforce Certified Business Analyst, UAT is not merely a testing exercise; it is a critical change management and business alignment milestone. The BA orchestrates the strategy, authors the plan, establishes objective quality gates, and guides business stakeholders through the validation process.

---

The Strategic Purpose of UAT in Salesforce Rollouts

To understand the role of UAT, business analysts must distinguish it from the earlier stages in the application lifecycle. Testing is not a monolithic activity; it progresses through distinct phases, each with unique owners, environments, and objectives.

The Testing Hierarchy: Unit Testing, SIT, QA, and UAT

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE SALESFORCE TESTING CONTINUUM                        │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. UNIT TESTING (Devs)    --> "Does the programmatic / declarative unit     │
│                                work in technical isolation?"                │
│  2. SYSTEM INTEGRATION     --> "Do Salesforce flows, APIs, middleware, and  │
│     TESTING / SIT (Dev/QA)     external endpoints exchange data cleanly?"   │
│  3. QUALITY ASSURANCE      --> "Does the build conform to the documented    │
│     TESTING / QA (QA Team)     technical specifications without regression?"│
│  4. USER ACCEPTANCE        --> "Does the solution support operational       │
│     TESTING / UAT (Users)      business processes and fulfill user needs?"  │
└─────────────────────────────────────────────────────────────────────────────┘

1. Developer Unit Testing

• Ownership: Salesforce Developers and Technical Administrators.
• Focus: Validating individual components in technical isolation. In Salesforce, this includes Apex test classes (satisfying the platform requirement of at least 75% code coverage for deployment to production), Flow test suites, and Lightning Web Component Jest tests.
• Scope: Verifies that a trigger executes without governor limit exceptions, that a Flow formula resolves null values, or that an Apex controller returns the expected JSON payload.

2. System Integration Testing (SIT)

• Ownership: Integration Engineers, Technical Architects, and QA Leads.
• Focus: Verifying that data flows seamlessly across system boundaries. In an enterprise landscape, Salesforce rarely operates in a vacuum; it connects to ERP systems (SAP, Oracle), billing engines (Stripe, Zuora), marketing automation (Marketing Cloud, HubSpot), and data warehouses (Snowflake).
• Scope: Validates REST/SOAP API contracts, middleware orchestration (MuleSoft), webhook event delivery, error retries, and high-volume data synchronization.

3. Quality Assurance (QA) Technical Testing

• Ownership: Dedicated Quality Assurance Engineers.
• Focus: Verifying that the configured software matches the documented technical specifications and functional requirements across end-to-end happy and negative paths. QA engineers execute regression suites (manual or automated using tools like Provar, Selenium, or Playwright) to ensure new features have not broken existing production functionality.
• Core Question: "Was the software built right?"

4. User Acceptance Testing (UAT)

• Ownership: Business Subject Matter Experts (SMEs), frontline end users, and business process owners—facilitated and guided by the Salesforce Business Analyst.
• Focus: Validating that real human users, operating within their authentic daily routines and using their natural business vocabulary, can successfully complete end-to-end business scenarios. UAT evaluates user experience, workflow continuity, terminology accuracy, report usefulness, and overall fitness for purpose.
• Core Question: "Was the right software built for the business?"

The Enterprise Salesforce Testing Hierarchy

---

Constructing the UAT Plan

A successful UAT cycle does not happen by accident; it requires a structured UAT Test Plan authored by the Business Analyst well before testing begins. The UAT Plan establishes the strategy, governance, timeline, and resources required for execution.

Core Elements of the UAT Plan

1. Test Objectives & Success Measures: Defines the business purpose of the testing cycle. Objectives must tie directly to business outcomes (e.g., "Validate that Inside Sales Representatives can qualify leads, generate multi-currency CPQ quotes, and submit discount approvals without manual intervention").
2. Scope Boundaries (In-Scope vs. Out-of-Scope): Establishes explicit guardrails around what will and will not be tested. Defining what is out-of-scope is just as crucial as defining what is in-scope. For example, the plan might state that standard Lead-to-Opportunity conversion is in-scope, while the automated ERP billing sync scheduled for Phase 2 is explicitly out-of-scope.
3. Schedule & Testing Milestones: Outlines the sequence of events: environment verification, tester kickoff, execution windows, daily triage meetings, re-test windows, and the final sign-off deadline. In agile projects, UAT may occur incrementally during sprint review cycles, but a consolidated end-to-end UAT window (typically 1 to 3 weeks depending on release scale) is required before major enterprise releases.
4. Logistics & Tooling: Specifies the test management tool (e.g., Jira, Azure DevOps, TestRail, or Salesforce Agile Accelerator), defect logging templates, virtual meeting links for daily standups, and dedicated communication channels (e.g., a dedicated Slack or Teams channel for real-time tester support).
5. Roles & Responsibilities: Formalized through a RACI matrix (Responsible, Accountable, Consulted, Informed) detailing the duties of the BA, Product Owner, QA Lead, Technical Architect, and business testers.

Role-Based Tester Selection: Who Should Test?

A frequent failure mode in Salesforce implementations is assembling the wrong group of testers. Selecting only senior leadership results in high-level testing that misses operational friction, while selecting only the project team introduces confirmation bias.

A balanced UAT tester cohort consists of three critical demographics:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE 3-TIER UAT TESTER DEMOGRAPHIC                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. FRONTLINE END USERS     --> Sales Reps, Support Agents, Field Techs     │
│                                 (Execute daily click paths & edge cases)    │
│  2. BUSINESS SMEs           --> Process Owners, Compliance, Team Leads      │
│                                 (Verify complex business logic & rules)     │
│  3. OPERATIONAL SUPERVISORS --> Sales Directors, Service Managers           │
│                                 (Validate dashboards, approvals & reports)  │
└─────────────────────────────────────────────────────────────────────────────┘

• Frontline End Users: The individuals who spend 40 hours a week inside Salesforce (e.g., Inside Sales Reps, Tier-1 Service Agents, Loan Processors). They possess intuitive knowledge of daily shortcuts, customer communication patterns, and ergonomic friction. If a Lightning page has too many clicks or mandatory fields in illogical positions, frontline users will immediately identify it.
• Business Subject Matter Experts (SMEs): Domain authorities who deeply understand organizational policies, regulatory rules, and commercial governance (e.g., Revenue Operations Managers, Pricing Specialists, Compliance Officers). SMEs validate complex calculation logic, discount approval matrices, and regulatory data retention.
• Operational Supervisors and Managers: Team leaders who rely on supervisory capabilities such as Omni-Channel Supervisor dashboards, Opportunity pipeline reports, team forecasting, and managerial approval queues.

[!WARNING] The Project Team Fallacy: Never allow Salesforce Administrators, Developers, or Business Analysts to act as proxy business testers during official UAT. Project team members suffer from "system familiarity bias"—they know how the system was configured, subconsciously avoid known bugs, and navigate the happy path without hesitation. UAT must be executed by authentic end users who have not participated in the day-to-day configuration.

---

Formal UAT Entry Criteria: Protecting Business Resources

Business users and SMEs are among the most valuable, time-constrained resources in an organization. Pulling them away from their revenue-generating or customer-facing responsibilities to test an unstable, unverified build damages project credibility and causes tester fatigue.

To prevent premature testing, the Business Analyst must establish and enforce strict UAT Entry Criteria. UAT cannot commence until every entry condition has been verified and signed off by the technical team.

The 6 Mandatory UAT Entry Criteria

┌─────────────────────────────────────────────────────────────────────────────┐
│                         MANDATORY UAT ENTRY GATES                           │
├─────────────────────────────────────────────────────────────────────────────┤
│  [✓] 1. QA & SIT Execution 100% Complete with Formal Sign-Off               │
│  [✓] 2. Zero Open Severity 1 (Critical) or Severity 2 (Major) Defects       │
│  [✓] 3. Dedicated Sandbox Provisioned, Refreshed & Sanity Tested            │
│  [✓] 4. Representative Business Test Data Seeded & Validated                │
│  [✓] 5. User Security, Profiles, Permission Sets & Queues Fully Configured  │
│  [✓] 6. Tester Enablement & Kickoff Orientation Completed                   │
└─────────────────────────────────────────────────────────────────────────────┘

1. QA and SIT Execution 100% Complete: All planned functional QA test scripts and system integration tests must have executed to completion. The QA Lead must provide formal written verification that the build meets all documented acceptance criteria.
2. Zero Open Severity 1 or Severity 2 Defects: No critical blockers (system crashes, data corruption, primary workflow breaks) or major defects (functional failures lacking simple workarounds) can remain open. Commencing UAT with open high-severity defects guarantees that business users will get blocked within minutes.
3. Dedicated UAT Sandbox Provisioned & Sanity Tested: Testing must occur in a stable, dedicated sandbox (ideally a Full Sandbox or robust Partial Copy Sandbox) that has been locked against ongoing developer code commits. The BA and QA Lead must execute a "smoke test" (sanity test) to verify that login flows, core navigation, and critical integrations are operational.
4. Representative Test Data Seeded: The sandbox must contain realistic, uncorrupted business data. Testing cannot succeed with blank tables or nonsensical dummy records (e.g., accounts named "Test12345"). Realistic accounts, parent-child hierarchies, product catalogs, price books, and contacts must be fully populated.
5. User Accounts & Security Configured: Testers must have active user records assigned to their exact real-world Profiles, Role Hierarchy nodes, Permission Sets, Public Groups, and Queue memberships. Single Sign-On (SSO) or multi-factor authentication (MFA) must be verified so testers can log in seamlessly on Day 1.
6. Tester Orientation Completed & Scripts Distributed: Testers must complete a formal kickoff session where they receive their test scenarios, learn how to log defect tickets with screenshots, and understand support channels.

---

Formal UAT Exit Criteria: Gating the Go-Live Decision

Just as Entry Criteria prevent premature testing, UAT Exit Criteria define the objective, non-negotiable conditions required to declare UAT complete and recommend the solution for production deployment.

Without explicit exit criteria, project teams face endless testing cycles, subjective debates, or political pressure to deploy prematurely despite significant operational risks.

The 5 Standard UAT Exit Criteria

1. 100% Test Scenario Execution: Every scheduled test scenario and test script in the UAT plan must have been executed by designated testers. No scenarios may remain in "Untested" or "In Progress" status.
2. Passing Threshold Achieved (Typically >= 95%): The overall test execution suite must satisfy an agreed-upon quantitative pass rate threshold. In enterprise Salesforce deployments, the industry standard is typically a minimum 95% first-pass or re-test pass rate across all executed test scripts.
3. Zero Unresolved Severity 1 or Severity 2 Defects: All Severity 1 (Blocker) and Severity 2 (Major) defects logged during UAT must be resolved, deployed to the sandbox, re-tested, and verified as closed by the reporting business user.
4. Documented Backlog & Workarounds for Residual Minor Defects: Any remaining Severity 3 (Minor) or Severity 4 (Cosmetic) defects must have:
   • An agreed-upon, documented operational workaround communicated to business users.
   • Formal backlog tickets logged and prioritized for post-go-live sprint releases.
   • Written acknowledgment from the affected business process owner that the defect does not block go-live.
5. Formal Business Acceptance Sign-Off: Designated business process owners, executive sponsors, and the Product Owner must execute a formal, written User Acceptance Certificate authorizing deployment to Production.

---

Realistic Scenario: The Cost of Bypassing UAT Entry Criteria

To understand why entry criteria are non-negotiable on enterprise Salesforce projects, examine this real-world scenario from an enterprise high-tech rollout.

The Context

NexGen Cloud, an enterprise B2B SaaS provider, was deploying Salesforce Revenue Cloud (CPQ) and Sales Cloud to 800 global sales representatives. The project was running two weeks behind schedule due to complex custom quote-calculator pricing plugins (QCP). Facing executive pressure to hit the end-of-quarter go-live date, the Project Manager decided to "fast-track" UAT.

The Decision & The Failure

• Entry Criteria Bypassed: Functional QA had only completed 80% of its test cases. Two known Severity 2 defects were still open: the custom pricing engine timed out when calculating quotes with more than 15 line items, and the 'Approval Status' field on the Quote object failed to lock records after submission.
• The Immediate Impact: On Day 1 of UAT, 25 regional sales managers and account executives logged into the sandbox. Within 45 minutes, 18 of the 25 testers created quotes exceeding 15 line items. Every single one encountered a fatal Apex CPU timeout error screen.
• The Consequence: UAT ground to a complete halt. Testers became intensely frustrated, took screenshots of the crash screens, and emailed the Chief Revenue Officer (CRO), stating: "The new Salesforce CPQ system is completely broken and our team cannot use it." Business leadership lost confidence in the platform. The testing window was abandoned, requiring four weeks of damage control, executive re-alignment, and remediation before UAT could be restarted.

The BA's Corrective Action

The Salesforce Business Analyst intervened and established formal governance for the restart:

1. UAT was formally suspended until QA completed 100% regression and verified zero open Sev 1/2 defects.
2. The BA conducted a comprehensive sandbox sanity test with real sales quotes.
3. When UAT restarted under strict entry criteria gates, the business users executed 142 end-to-end scenarios with a 97% pass rate, resulting in enthusiastic business sign-off.

---

Common Exam Traps & Real-World Anti-Patterns

• Trap 1: Conflating QA with UAT: Exam questions frequently describe scenarios where technical QA testers or developers execute test scripts in a sandbox and ask if this constitutes UAT. Remember: UAT is fundamentally defined by who tests (business end users and SMEs) and what they evaluate (operational business workflow continuity, not code syntax or technical specification compliance).
• Trap 2: Using UAT as Discovery or First-Time Demos: If business stakeholders are seeing the configured Salesforce application for the very first time during UAT, the project methodology has failed. In agile frameworks, stakeholders should have seen working increments during bi-weekly Sprint Reviews. UAT is an evaluation of operational readiness, not an elicitation session for new requirements.
• Trap 3: Commencing UAT Under Schedule Pressure Without Meeting Entry Criteria: When a project is behind schedule, stakeholders often suggest "overlapping" QA and UAT to save time. Exam scenarios testing this will look for the BA's response: the BA must advise against starting UAT until entry criteria (especially zero open Sev 1/2 defects and verified test data) are strictly satisfied.
• Trap 4: Permitting Informal or Verbal Sign-Off: An executive saying "Looks great in the meeting!" or sending a thumbs-up emoji on Slack does not constitute formal UAT sign-off. The exam emphasizes governance: UAT exit requires an auditable, written acceptance certificate signed by designated business process owners.