Planning UAT

Why it matters

The scarcest resource in UAT is the users’ time: accountants, nurses or branch staff released from full-time jobs for a few days. Without a plan those days are lost to missing accounts, meaningless data, an unstable build or nobody to answer questions; users stop coming, and acceptance is decided on thin evidence.

For a tester, planning is most of the UAT work: the business judges the result, and the QA side makes judging possible. A gap found while planning costs a meeting; found on the first UAT morning, it costs a day of every participant’s time.

Scope: business processes, not screens

Write the scope as the business processes to accept and the roles that perform them, each traced to its acceptance criteria. "Test the claims screen" is not a scope; "an employee submits a claim, a line manager approves it and finance pays it" is. Each process later becomes UAT scenarios, the subject of the next lesson.

UAT is not a second round of system testing: field validation and boundary values were checked at system level. When time is short, let product risk choose: processes with the highest business impact or the most change come first.

• Out of scope, stated explicitly: for example performance, unchanged reports or features for a later release.
• Planned elsewhere: operational acceptance (backup, restore, monitoring) has its own owner; the UAT plan refers to it.

Try it: Risk-Based Test Generator Try it: Requirements → Test Cases

Participants: business roles and QA roles

Name participants for each role in scope: people who do the work every day, experienced and new, not only managers or super-users who know the workarounds. Add the business process owner, who decides, and confirm with each participant’s manager that their time is released.

The ISTQB Foundation syllabus says acceptance testing is ideally performed by the intended users. The QA side prepares and supports but never accepts for the business; if testers run the scenarios because users have no time, that is more testing by testers, not user acceptance.

• Business process owner, often the product owner: approves scope and priorities, and decides acceptance.
• Business users: perform the scenarios in their own role and judge whether the system supports their work.
• UAT coordinator, often the QA lead (in some teams a business analyst): writes the plan, runs the schedule and the daily triage.
• Testers: draft scenarios with users, prepare environment, data and accounts, support users and confirm fixes before users retest.
• Developers and operations: fix defects and deploy agreed builds.

The schedule: work back from go-live

Build the schedule backwards from go-live, which is usually fixed, and book the users as soon as the dates are agreed. Avoid the business’s busy periods, such as month-end closing for a finance team. If the entry check fails, move the start or reduce the scope; never quietly shorten the users’ time.

• Preparation: environment, data, accounts and scenarios, from the day the scope is agreed.
• Entry check: a few days before the start, while there is still time to react.
• Briefing on the first morning: scope, how to record results and defects, whom to call.
• Execution with daily triage, then fixes, confirmation testing by testers and retesting by users.
• Sign-off, then release preparation.

Try it: Date Calculator

Environment, data, entry and exit criteria

The UAT environment should resemble production as closely as the project can afford: the same configuration, roles, permissions and integrations, or agreed simulators. Keep it separate from system testing and deploy new builds only at agreed times, so that a scenario passed on day 2 is not silently invalidated on day 3.

Data must make sense to users: realistic employees and approval limits, and records already in the states the scenarios need, such as a claim awaiting approval. Masked production data still needs the personal-data protection from the lesson on test data; synthetic data is safer, and users can help make it realistic. Give each participant their own account, never a shared one, so every result shows who did it.

Entry criteria turn this preparation into a gate. The ISTQB syllabus groups typical entry criteria into available resources, available testware and the initial quality of the test object, the first three items below. The plan also states the exit criteria the business owner will decide against at the end of UAT, and when sessions are suspended and resumed:

• Initial quality: system testing exit criteria met, no open Blocker or Critical defect in scope, smoke test passed on the UAT build.
• Resources: environment and data ready, every account tested, participants’ time confirmed.
• Testware: acceptance criteria agreed, scenarios reviewed by the business, defect reporting ready.
• Exit criteria: every planned scenario executed, no open Blocker or Critical defect, and every acceptance criterion met or covered by an agreed condition.
• Suspension and resumption: suspend a session when a blocking defect or an environment failure stops most scenarios; resume when a fixed build has passed the smoke test.

Try it: Fake Employee Generator Try it: Test Data Factory

Worked example: a UAT plan for expense claims

For the expense-claims module, the QA lead drafts the plan with the finance director and the product owner. Days are working days counted from its approval; go-live is on day 22.

• Scope: submit with receipts, approve or reject, pay, nightly export to accounting. Out of scope: mileage claims (next release), backup and restore (operational acceptance).
• People: three employees, two line managers, two finance officers; the finance director decides; the QA lead coordinates.
• Environment and data: linked to the accounting system’s test instance; 60 synthetic employees with managers and approval limits; claims in every status; seven personal accounts.
• Entry: the three groups of criteria above, checked against evidence on day 8.
• Exit: every planned scenario executed, no open Blocker or Critical defect, and every acceptance criterion met or covered by a condition the finance director agrees; a session is suspended if a blocking defect stops most scenarios and resumed on a fixed build that has passed the smoke test.
• Schedule: preparation days 1–10, briefing and execution days 11–16, fixes and retests 17–19, sign-off day 20, release preparation day 21, all clear of month-end closing.
• Risk: a finance officer is on leave on days 15–16, so a named stand-in is briefed too and gets an eighth account.

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019ISTQB's specialist syllabus on acceptance testing: user, contractual and regulatory acceptance testing, alpha and beta testing, and how testers work with product owners and business analysts.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.
• Personal Data Protection Law (English translation)Saudi Data & AI Authority (SDAIA) · 2023The Saudi law governing personal data — why test environments should use synthetic data rather than copies of real customer records.