UAT Planning and Execution

User Acceptance Testing (UAT) is the final test cycle before a system goes live. Real business users (not QA testers) execute test scenarios against the system in a staging environment. UAT is where the BA's requirements meet the actual users for the first time, and where late-stage problems get caught at the cheapest moment to fix them.

In SA enterprise, UAT is often the BA's responsibility to plan, coordinate and report on. This lesson covers how to do it well.

UAT vs the other testing stages

UAT is not the only kind of testing. Knowing the difference saves a lot of awkward scope conversations.

Stage	Who runs it	What it tests
Unit test	Developers	Individual functions and components in isolation
Integration test	Developers / QA	Components working together; API contracts
System test	QA team	End-to-end system behaviour against the spec
UAT	Real business users	Whether the system actually meets the business need
Production verification	Business + QA	After go-live, that everything still works in the production environment

UAT is the only stage that asks "does this solve the business problem", not "does this meet the written spec". Sometimes a system passes system test but fails UAT because the spec did not capture the real-world workflow.

Planning a UAT cycle

A typical UAT cycle for an SA enterprise project takes 2-4 weeks. The plan covers six things.

Scope

Which features, which user journeys, which business processes are in the UAT. Should map to the BRD and FRS for traceability.

Test environment

Staging environment with production-like data (anonymised). Stable enough that defects are reproducible. Often a separate UAT environment from the regular dev/QA environments.

Test scripts

Scenario walkthroughs the UAT users follow. Each script lists the steps, the expected result and a place to log the actual result. Derived from acceptance criteria and use cases.

Participants

Real business users from the teams who will use the system in production. 5-12 users for mid-sized projects. Should include power users and average users, not just the eager volunteers.

Defect triage process

How issues found during UAT get logged, prioritised, fixed and re-tested. Usually a daily triage meeting during UAT.

Sign-off criteria

What 'UAT complete' looks like. Often: '95% of test scripts passed; no P1 or P2 defects open; business sponsor signs UAT acceptance form.'

Writing test scripts

Each test script is a self-contained scenario a user can execute without external help.

UAT-TS-014: Submit motor quote for a young driver with claims history

Preconditions:
  - You are logged in as a broker
  - You have access to the new motor quote screen

Steps:
  1. Click "New Motor Quote"
  2. Enter the following vehicle details:
       Make: Toyota
       Model: Corolla 2024
       Value: R350,000
       Postcode: 2196
  3. Enter the following driver details:
       Age: 22
       Licence years: 2
       Claims (last 3 years): 1 minor accident, 2024
  4. Click "Generate Quote"

Expected result:
  - The system displays "Pending underwriting review"
  - The quote is saved with status "Pending"
  - The underwriting team receives a notification

Actual result:                          [Pass / Fail]
Notes:

Defect triage during UAT

Defects flow daily. The triage process keeps the flow under control.

Log

User finds an issue, logs it in the project tracker (Jira, Azure DevOps) with steps to reproduce, expected vs actual behaviour, screenshots.

Categorise

Defect severity: P1 (blocking), P2 (major), P3 (minor), P4 (cosmetic). Defect type: bug, scope gap, training need, environment issue.

Triage daily

BA, dev lead, QA lead meet for 30 minutes daily. Walk the open defect list. Assign owners. Decide which defects block UAT closure.

Fix and re-test

Dev fixes P1 and P2 defects fast. P3 and P4 deferred to backlog if not blocking. Re-tested by the original UAT user.

Report

Daily defect dashboard: total open, open by severity, opened today, closed today. Sent to the project sponsor.

Sign-off criteria

UAT is complete when explicit criteria are met. The BA defines these up-front, before UAT begins.

Typical UAT sign-off criteria

1. 95%+ of test scripts have been executed and passed. 2. Zero P1 defects open. 3. Zero P2 defects open (or each open P2 has documented business acceptance to release). 4. Sponsor has reviewed the test report and signed the UAT acceptance form. 5. Training and operational readiness items (rollback plan, support documentation, comms to users) are checked off.

Criteria need to be agreed before UAT starts. Negotiating sign-off criteria during UAT becomes a power struggle.

Common UAT failures

UAT used as 'system test by users'

Users find defects QA should have found in system test. Means QA's coverage was thin. UAT becomes the QA team's safety net rather than business validation.

Volunteers only

Only enthusiastic users participate; average users do not. UAT shows the system works for power users and misses problems average users hit.

Test environment is unstable

Defects are environment-related (data missing, integrations not configured), not real product issues. Wastes everyone's time. Verify the environment before UAT starts.

Test scripts are too prescriptive

Step-by-step scripts force users to follow a path. Real users explore. Allow exploratory time in the UAT plan in addition to scripted scenarios.

Triage falls behind

Defects pile up. Users wait for fixes. UAT timeline slips. Discipline of daily triage is what prevents this.

SA enterprise UAT patterns

Branch-based UATBanking and retail UATs often happen in a real branch with a controlled subset of customers. Allows real-world behaviour testing.

Parallel runFor systems replacing legacy, the old and new systems run in parallel for a week or two. Users compare outputs. Common for core-banking, claims and policy admin replacements.

HypercareAfter go-live, a 2-4 week period of heightened support where the project team is on-call. Sometimes considered part of the UAT cycle.

Regulator-witnessed UATFor regulator-driven systems (POPIA compliance modules, FAIS suitability tools), the regulator may observe or participate in UAT.

Key Takeaways

UAT validates business need, not just spec. Different from system test.
Six planning items. Scope, environment, scripts, participants, triage, sign-off criteria.
Daily defect triage. Log, categorise, prioritise, fix, retest, report.
Sign-off criteria up-front. 95%+ scripts pass, P1/P2 cleared, sponsor signs.
SA patterns. Branch-based, parallel run, hypercare, regulator-witnessed.