Design End-to-End UAT Scenarios on Synthetic Data That Never Touches Production

Workflow area: UAT & Testing · Tier: Core · Hands-on time: ~35 minutes

Two failure patterns meet in this playbook. First: UAT packs that pass every atomic test while the end-to-end journey — the return that arrives after the refund policy changed, the approver on leave mid-workflow — was never exercised, because nobody designed scenarios above the test-case level. Second: the near-universal shortcut of copying production data into the test environment "because it's realistic," which puts real customers' personal data in the least-controlled environment in the estate. AI fixes both at once: it is genuinely good at composing journey narratives from personas, and even better at generating data that is statistically realistic and legally boring.

When to use — and when not to

• Use it when UAT needs to prove journeys, not just requirementscross-module flows, month-end sequences, exception handling that spans days and roles.
• Use it whenever a test environment needs populationdatasets with realistic distributions, edge cases planted deliberately, and zero real people.
• Use it for personas the requirements underservedthe occasional user, the user with delegated authority, the account with seven years of messy history.
• Skip it for interface and migration reconciliation testingthose must run against controlled real-data copies under a proper legal basis and access regime; synthetic data cannot validate a migration's fidelity.
• Skip "anonymized" production shortcutsmasking names while keeping real transaction patterns often stays re-identifiable; generate from scratch instead of scrubbing.
• Skip volume/performance testing scopesynthetic UAT data proves function at business scale, not infrastructure behavior at load; that is a different exercise with different data volumes.

The recipe

1. 1.

   Define the personas and journeys with the business, not the model. List the user types that matter — including the inconvenient ones (new joiner with no history, power user with edge-case permissions, customer mid-dispute) — and the journeys each must survive: the routine one, the exception one, the one that spans a period boundary. The AI expands this; it should not originate it.

2. 2.

   Generate the scenario suite. With personas, journeys, and the requirements pack attached:

   Copy

   You are designing end-to-end UAT scenarios. Attached:
   personas, journey list, requirements pack.
   
   For each persona × journey, produce a scenario: SC-ID |
   persona | narrative (3-6 sentences: realistic sequence of
   business events over days/weeks, in business language) |
   step table: day/step | actor | action | expected observable
   outcome | requirements exercised (IDs).
   
   For every scenario also produce:
   - one NEGATIVE variant (a step fails, is refused, or is
     abandoned midway — what should the system and process do?)
   - one BOUNDARY variant (limits, cutoffs, period-ends,
     permission edges).
   Rules: scenarios must cross at least two modules or process
   stages; cite requirement IDs per step; if a journey step has
   no supporting requirement, flag REQUIREMENT GAP rather than
   inventing behavior.
   

   The REQUIREMENT GAP flags are elicitation findings in their own right — journeys are where missing requirements hide.

3. 3.

   Specify the data before generating it. For each entity, write a one-line data spec with the distributions that matter: "5,000 customers: 60% consumer / 40% business, 8% with credit blocks, 3% with non-Latin names, ages 18–95, 2% sharing a surname and address (household, not duplicate)." Planted edge cases are the point — a dataset without awkward records tests nothing.

4. 4.

   Generate synthetic data with realism rules and a no-real-people contract. Per entity:

   Copy

   Generate [N] synthetic [ENTITY] records as CSV matching this
   schema: [FIELDS, TYPES, CONSTRAINTS].
   Distributions: [PASTE SPEC]. Plant these edge cases with
   flags in an extra qa_note column: [LIST].
   Rules: names, addresses, emails, phone numbers, and IDs must
   be plausible in format but verifiably fake — use reserved
   test ranges where they exist (e.g. 555 phone prefixes,
   example.com emails, invalid-checksum tax IDs). Never emit a
   real person's name-plus-address combination. Referential
   integrity: child records must reference generated parent
   keys only. Include a data dictionary listing every rule.
   

   For volumes beyond chat scale, have the AI write a generation script (Python/Faker) instead — same spec, same rules, repeatable on demand.

5. 5.

   Validate the data like you'd profile a source. Run a quick profile (see the data-profiling playbook): distributions match spec, referential integrity holds, planted edge cases are present and flagged, and formats pass the target system's validation. Then load and smoke-test one scenario end to end before UAT week — data that will not load is the most common UAT day-one delay.

6. 6.

   Walk the scenarios with the business owner and script the residue. Owners review scenario narratives fast because they read like the actual business. Capture their corrections ("returns never skip inspection — who told you that?") as scenario fixes and, where the correction contradicts a requirement, as change findings. Final pack: scenario suite with negative and boundary variants, generated datasets plus dictionary and generation script, and the REQUIREMENT GAP log routed back to the requirements owner.

Make it yours

• Faker-class generation scripts for scale: chat-generated CSVs suit hundreds of rows; scripted generation suits hundreds of thousands, versioned in the repo and rerun per environment refresh.
• Dedicated synthetic-data tools for relational depth: where the schema spans dozens of linked tables, purpose-built generators maintain referential webs better than prompting — use the AI to write their configuration from your data spec.
• Claude Project as the scenario workshop: personas, requirements, and scenario suite in one project lets the business owner's corrections regenerate affected scenarios without starting over.
• Regression reuse: keep the scenario suite and generation script as standing release assets — every future release replays the same journeys on freshly generated data, which is exactly what regression UAT should be.

Quality check

• Scenarios span modules and timeeach crosses at least two process stages and exercises sequencing, not just screens.
• Every scenario has negative and boundary variantsrefusals, abandonments, cutoffs, and permission edges are tested deliberately.
• REQUIREMENT GAP flags were routedjourney steps with no supporting requirement became raised findings, not invented behavior.
• The data is verifiably fakereserved test formats, invalid-checksum IDs, no real name-address combinations; a spot-search confirms it.
• Planted edge cases are present and flaggedthe profile shows spec-matching distributions and every qa_note case loaded.
• The business owner walked the narrativescorrections captured, and the suite reflects how the business actually behaves.