10.2 Test Scenarios, Test Scripts & Sandbox Environment Preparation

10.2 Test Scenarios, Test Scripts & Sandbox Environment Preparation

Quick Answer: End-to-end UAT test scenarios bridge the gap between bite-sized sprint user stories and continuous business operations. While a user story validates an isolated action (e.g., converting a lead), a UAT scenario validates cross-object, multi-persona business journeys (e.g., Lead-to-Cash or Case-to-Resolution). High-quality UAT scripts must explicitly document prerequisites, step-by-step click paths, and expected results across Positive, Negative, Boundary, and Security/Profile paths. To ensure environmental fidelity without regulatory compliance violations, UAT should execute in a Full or Partial Copy Sandbox protected by Salesforce Data Mask to obfuscate Personally Identifiable Information (PII).

In an agile Salesforce implementation, delivery teams work in sprint-sized increments. Developers build individual user stories, administrators configure discrete validation rules, and QA engineers verify isolated functional acceptance criteria. However, business users do not operate in two-week sprint chunks or single-object silos.

A sales representative does not care whether a lead conversion is managed by an automated Flow while quoting is handled by Salesforce CPQ and approvals are processed by an advanced approval engine; they care that a customer inquiry transitions seamlessly into a signed contract and provisioned order. The Salesforce Business Analyst plays the essential role of translating atomized user stories into realistic, end-to-end business test scenarios and preparing an authentic sandbox environment where testing can succeed.

---

Translating User Stories into End-to-End Business Scenarios

During requirements analysis and sprint execution, user stories are intentionally decomposed using the INVEST framework to ensure they are small, independent, and deliverable within a single sprint. However, testing these stories in isolation during UAT creates blind spots: it fails to validate record handoffs between departments, data consistency across lifecycle stages, and asynchronous background automations.

The Business Analyst utilizes the Requirements Traceability Matrix (RTM) to bundle interconnected user stories into End-to-End (E2E) Business Scenarios.

┌─────────────────────────────────────────────────────────────────────────────┐
│            TRANSLATING USER STORIES INTO AN END-TO-END SCENARIO             │
├─────────────────────────────────────────────────────────────────────────────┤
│  SPRINT USER STORIES:                                                       │
│  • US-101: Web-to-Lead Assignment Rules & Duplicate Detection (Sprint 1)   │
│  • US-104: Lead Qualification & Account/Contact/Opp Conversion (Sprint 2)   │
│  • US-112: Opportunity Stage-Gate Validation & Price Book Selection (Sprint 3)│
│  • US-118: Multi-Line CPQ Quoting & Non-Standard Discount Approvals (Sprint 4)│
│  • US-125: Adobe Acrobat Sign Integration & Contract Activation (Sprint 5)  │
│                                     │                                       │
│                                     ▼                                       │
│  UAT END-TO-END SCENARIO (Scenario E2E-01: "Enterprise Lead-to-Contract"):  │
│  "Execute a complete commercial customer acquisition journey from inbound    │
│   marketing lead capture through multi-tier discount approval, executive     │
│   e-signature execution, and automated contract generation."                │
└─────────────────────────────────────────────────────────────────────────────┘

Business Scenarios vs. Test Scripts

• Business Scenario: A narrative, high-level overview describing an end-to-end business journey, its operational context, the personas involved, and the overall business objective. Scenarios explain why the process matters and what operational milestone is being accomplished.
• Test Script (Test Case): The granular, step-by-step procedural instruction that guides a specific tester through the application. Scripts define where to click, what specific test data to input, what outcome to observe, and how to verify pass/fail status.

---

Structuring Professional Salesforce Test Scripts

A common pitfall in UAT is providing testers with vague instructions such as "Log in and try to create a quote to see if it works." Such ambiguity results in incomplete coverage, untestable feedback, and unrepeatable defect logs.

A standardized, enterprise-grade Salesforce test script must contain the following core attributes:

1. Test Script Identifier & Traceability Link: Unique ID (e.g., TC-CPQ-024) linked directly to the Epic, User Story, or RTM requirement number.
2. Test Title & Objective: Concise summary of what is being validated (e.g., "Validate Deal Desk Approval Routing for Non-Standard Payment Terms").
3. Target Persona & User Profile: The exact role and profile under which the test must be executed (e.g., "Persona: Commercial Account Executive; Profile: Standard Sales User; Permission Set: CPQ Standard User").
4. Preconditions & Prerequisites: The exact system state required before beginning step 1 (e.g., "An active Customer Account 'Apex Global' exists; Opportunity 'Apex Expansion' is in stage 'Proposal/Price Quote'; User has active CPQ license").
5. Required Test Data: Explicit data values to use during execution (e.g., "Product SKU: CLOUD-ENTERPRISE-01; Quantity: 50; Discount: 25%; Payment Terms: Net 60").
6. Step-by-Step Actions: Numbered, sequential, unambiguous click-path instructions (e.g., "1. Open Opportunity 'Apex Expansion'. 2. Click 'New Quote'. 3. Select Price Book '2026 Direct Commercial'").
7. Expected Outcome: The precise, verifiable system behavior and business state change (e.g., "Quote lines calculate with 25% discount; 'Approval Required' banner displays; status updates to 'In Review'; automated approval notification is routed to the Regional Sales Director").
8. Actual Outcome & Status: Field populated by the tester during execution documenting what occurred, accompanied by a status flag: Pass, Fail, or Blocked.
9. Evidence & Attachments: Mandatory screenshots or screen recordings showing successful execution or error dialogs, including the Salesforce Record ID and URL.

Comparative Analysis: Poor vs. High-Quality UAT Test Script

---

The 4 Essential Testing Varieties in UAT

To achieve comprehensive coverage, a Business Analyst must design test scripts that span four essential testing variations. Novice teams focus exclusively on the "happy path," allowing validation flaws, security leaks, and edge-case exceptions to slip into Production undetected.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE 4 ESSENTIAL UAT TESTING VARIETIES                   │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. POSITIVE PATH        --> The standard success flow with valid data      │
│  2. NEGATIVE PATH        --> Validation rules, missing fields & error paths │
│  3. BOUNDARY TESTING     --> Threshold limits, maximum characters & cutoffs │
│  4. SECURITY & ROLES     --> CRUD, FLS, Dynamic Forms & Record Sharing      │
└─────────────────────────────────────────────────────────────────────────────┘

1. Positive Path Testing (Happy Path)

Validates that when business users enter clean, valid data and follow standard operational operating procedures, the transaction completes successfully and advances to the correct downstream state.

• Example: A Customer Support Agent logs a Case with a valid Contact and Account, selects Category 'Billing', enters a Subject, and clicks Save. The case saves, assigns to the Billing Queue, and starts the 4-hour SLA milestone timer.

2. Negative Path Testing (Validation & Error Handling)

Validates that when business users provide invalid data, omit mandatory information, or attempt an unauthorized action, the platform enforces business policy and presents clear, user-friendly error messages rather than unhandled system faults.

• Example: A Sales Rep attempts to close an Opportunity as 'Closed Won' without completing the mandatory 'Competitor Lost To' or 'Primary Win Reason' fields. The system blocks the save and displays the inline validation error: "Closed Won opportunities require a documented Primary Win Reason."

3. Boundary Value Testing

Validates system behavior at the exact boundaries of business rules and thresholds. In business logic, errors disproportionately cluster around threshold boundaries (e.g., greater than vs. greater than or equal to).

• Example: Business policy states that discounts up to 15.00% are auto-approved, discounts from 15.01% to 25.00% require Sales Director approval, and discounts exceeding 25.00% require VP approval. The BA must author test scripts for exactly 15.00% (auto-approves), 15.01% (routes to Director), and 25.01% (routes to VP).

4. Security, Profile & Permission Testing

Validates that user access controls (Object-Level CRUD, Field-Level Security, Record Sharing Rules, and Dynamic Forms component visibility) work correctly across different organizational personas.

• Example: An Inside Sales Rep and an HR Business Partner view the same Employee Contact record. The Sales Rep must not see the 'Compensation Tier' or 'Social Security Number' fields, while the HR Partner has full read/write visibility. Testing must be executed by logging in as each authentic persona.

---

Salesforce Sandbox Environment Selection for UAT

Executing UAT in the wrong Salesforce environment invalidates test results. If the environment lacks authentic data, business users cannot evaluate realistic workflows. If the environment contains live unmasked customer data, the organization violates legal and compliance mandates.

Salesforce provides four distinct sandbox types. Selecting the appropriate tier is a strategic architectural decision balancing data storage, refresh intervals, and cost.

Comparative Analysis of Salesforce Sandbox Tiers

Optimal Sandbox Recommendations for UAT

• Enterprise Rollouts: A Full Sandbox is the gold standard for final, pre-deployment UAT. It contains the complete customer database, active price books, account hierarchies, and historical records. This allows users to test high-volume reporting, batch Apex jobs, and complex CPQ pricing without data starvation.
• Agile Sprint UAT & Mid-Market Orgs: A Partial Copy Sandbox is highly effective when paired with well-crafted Sandbox Templates. A Sandbox Template defines which objects and related child records (e.g., Accounts, Contacts, Products, Price Books, and 10,000 sample Opportunities) are copied from Production, providing realistic testing without requiring the massive cost or 29-day refresh cycle of a Full Sandbox.

---

Data Privacy, Compliance & Seeding Representative Test Data

While a Full or Partial Copy Sandbox provides valuable operational realism, copying Production data into non-production environments introduces severe regulatory and legal liabilities.

Regulatory Compliance & Salesforce Data Mask

Under global privacy regulations such as the General Data Protection Regulation (GDPR), California Consumer Privacy Act (CCPA), and Health Insurance Portability and Accountability Act (HIPAA), non-production environments (which are accessible by external contractors, offshore developers, and broad tester groups) must never contain unmasked Personally Identifiable Information (PII) or Protected Health Information (PHI).

To resolve this tension between data realism and legal compliance, Salesforce provides Salesforce Data Mask—a native, powerful managed package that executes directly within the sandbox immediately following creation or refresh.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     SALESFORCE DATA MASKING TECHNIQUES                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. PSEUDONYMIZATION     --> Replaces PII with realistic fictional data     │
│                              (e.g., John Doe -> Marcus Vance; real phone    │
│                              -> +1-555-0199 from built-in library)          │
│  2. ANONYMIZATION        --> Replaces sensitive characters irreversibly     │
│                              (e.g., SSN 123-45-6789 -> ***-**-**** or random│
│                              hash strings)                                  │
│  3. DELETION             --> Permanently purges sensitive field values      │
│                              (e.g., Credit Card tokens, biometric data, or   │
│                              confidential executive notes erased completely)│
└─────────────────────────────────────────────────────────────────────────────┘

• Pseudonymization (Realistic Fictionalization): Replaces sensitive customer data with plausible, synthetic values from pre-built libraries. Real customer names are replaced with synthetic names, real street addresses with fictional addresses, and real email addresses with @example.com domains. This preserves the visual realism necessary for business testing without exposing live personal data.
• Anonymization (Pattern Obfuscation): Replaces characters with random hashes or standard masking formats (e.g., converting tax identifiers to XXX-XX-XXXX).
• Deletion: Erases high-risk data points entirely from sandbox records where the field is not required for testing.

Seeding Representative Test Data

When testing in Partial Copy or Developer Pro sandboxes where production data is incomplete, the BA must coordinate test data seeding prior to UAT kickoff:

• Relational Integrity: Ensure parent records (Accounts) exist before loading child records (Contacts, Cases, Opportunities). Orphaned records cause validation and lookup failures.
• Active Metadata Dependencies: Verify that referenced Picklist values, Record Types, Currencies, and Active Price Books match current operational standards.
• Integration Mocks: Ensure third-party integration endpoints in the sandbox (e.g., ERP billing, credit check APIs, address verification services) point to external staging/mock sandboxes rather than live production endpoints.