User Acceptance Testing Plan: Template, Steps and Criteria

A user acceptance testing plan is a document that describes how the business will verify, prior to go-live, that the software delivered will function for the purpose(s) it was purchased. It defines the scope, testers, environment, scenarios, pass/fail criteria, defect management and approvers. Agree on those nine items and UAT will no longer be a point of contention at the end of your project. This guide provides you the template, working examples and connection to site acceptance testing (SAT) for projects involving installed equipment.

Preparing Your PODTECH Build Software for Acceptance. PODTECH custom builds enterprise software for mission critical infrastructure. Products range from building telemetry and automation software to scalable SaaS applications. Learn More

TL;DR

UAT Plan:

Objectives and scope, Roles, Entry and exit criteria, Environment & Data, Scenarios, Defect management, Schedule, Risks and sign-off

UAT answers the question of "Can we do our real work with this solution?" It is not a second phase of QA.
Write scenarios as use cases in business terms, flows from end to end that are approximately 5-9 steps with visible results.
Include numbers in your exit criteria such as pass rate and number of open defects by severity, and include the name of the person who may accept the risk if it does not meet criteria.

SAT is the supplier/contractor-led verification of installed systems functionality on site. UAT is the subsequent user-led verification performed in actual operating conditions.

What a UAT plan is, and what it is not
The sections a UAT plan needs
Define scope, including what is out
Roles: who tests, who decides
Environment and data
Writing scenarios that reflect real work
Entry criteria: when UAT may start
Exit criteria and the sign-off decision
Defect handling during UAT
Schedule and contractual windows
Site acceptance testing: the on-site step before UAT
Perspective: acceptance is where reliability gets decided
Common mistakes to avoid
Plan acceptance with the people who build for critical infrastructure
FAQ
Sources

What a UAT plan is, and what it is not

UAT stands for User Acceptance Testing. This is usually the final testing phase that occurs late in the software development lifecycle using a production or production-like environment. Real users or representatives verify agreed business requirements are met and the software is ready for release. UAT is sometimes referred to as end-user testing or application testing.

The plan is your contract with the business for that stage of the project. Without one, testers do not know what is in scope. Developers debate if something is a defect or a CR. And no one knows when testing is complete.

One differentiation is important right from the beginning. Functional and system testing are concerned with whether the software works according to specification. UAT is concerned with whether the business can do the required work under realistic conditions well enough to accept the solution. The linked article also states that ultimate decision should rest with a stakeholder authorised to accept the solution and its residual risks. Your plan should identify who that is.

The analogy with system integration testing holds true here as well. SIT is QA-led and system-focused. UAT on the other hand is business requirement-led from the user's perspective. If your UAT scripts sound like technical test cases, the business testers will either bypass them or blindly tick them.

The sections a UAT plan needs

Different published templates use different labels but are consistent on what they include. One popular template includes objectives and scope, roles and responsibilities, entry and exit criteria, environment and data requirements, test case inventory and assignment, defect management, schedule, risk log, and sign-off procedure. Yet another template includes overview, test cases, and sign-off in addition to criteria, environment, schedule, roles, defects and risks.

Here is a structure you can copy.

Section	What it contains	Common failure if missing
Overview and objectives	What is being accepted, the business outcome, the release or build	Testers check features, not outcomes
Scope and exclusions	In-scope processes, out-of-scope items, interfaces covered	Scope creep and endless defect debates
Roles and responsibilities	Test lead, business testers, QA support, defect triager, approver	Nobody owns the decision
Entry criteria	Conditions that must be true before UAT starts	UAT begins on an unstable build
Environment and data	Production-like setup, accounts, data, integrations	Results that do not predict live behaviour
Scenarios and test cases	Business workflows linked to requirements	Gaps in coverage
Schedule	Windows, retest cycles, dependencies	Testers pulled back to day jobs
Defect management	Severity scale, triage, retest, waivers	Arguments at the end
Exit criteria and sign-off	Thresholds, approver, evidence, report	Acceptance by default
Risks and contingencies	What could stall UAT and the response	Surprises in the last week

Make the plan short enough for testers to read it. Ten to fifteen pages for a sizable program is sufficient. Two pages is fine for a small release.

Define scope, including what is out

When writing scope, do it as a list of business processes. "Raise a purchase order and have it approved" is an example of a scope line. "Approval module" is not.

Next write the exclusions. One practitioner guide states it rather well: if reporting is out of scope for the first UAT round and nobody records it, teams spend days firefighting report defects that nobody agreed to fix before go-live. Add each exclusion to the plan along with the reason and when it will be tested, whether that is a future date or future release.

Add regulatory references applicable to regulated releases, approvals needed and evidence that will be submitted. UAT plan for regulated SaaS releases also recommends you should define traceability, defect policy, change control and triggers/steps of rollback plan.

Roles: who tests, who decides

Describe a functional UAT team. Provide one role for each of the five functions. Identify an individual, not a department.

UAT lead: owns the plan, schedule and reporting.
Business testers: people who do this work every day. They run the scenarios.
QA or product support: reproduces failures, separates defects from misunderstandings.
Defect triager: agrees severity and routes each finding to the delivery team.
Acceptance approver: stakeholder who has authority to accept the solution and residual risk.

Schedule book tester time. UAT goes nowhere quietly when testers are buried in email and have ninety minutes free per week. Have it in the schedule, and get commitments from their managers.

Environment and data

Production environment should be mimicked as closely as possible in UAT environment. Tips on UAT checklists talk about real data, real configs and real system integration. Here's what that means in reality:

The release-candidate build deployed, not a developer branch.
Test accounts with the same roles and permissions as live users.
Representative data, masked where necessary, if it contains personal or confidential information.
Live connections to external systems the software interfaces with, or stubbed connections if live connections cannot be established.
A defined reset procedure to return to a known state so a tester can recreate the scenario from a consistent starting point.

If software interfaces to physical systems, whether it's a building management platform or a sensor network, identify which integrations are real and which are mocked. Placing that decision in the plan is important, because it determines what a pass will actually prove. We have a glossary entry for the BMS, or building management system, that defines the layer many integrations sit on top of.

Writing scenarios that reflect real work

Scenarios drive the quality of UAT. Base your testing on scenarios derived from your written acceptance criteria and user stories into full end-to-end scenarios that are easily understood by a business user. Include a goal, initial conditions, steps with expected results. Write these in business terms.

A guide to scenario writing suggests business value and end-to-end workflows, not technical UI clicks, 5 to 9 steps with observable outcomes. From that same guide:

Keep record for each scenario:

An ID linked to the requirement or epic.
The business outcome.
Trigger and preconditions.
Actors and roles.
A step-by-step narrative.
Expected results and the evidence to capture.
Risk and priority.
Links to acceptance criteria and related regression tests.

A worked example

Imagine a safety-incident reporting app for construction sites. A site supervisor fills out an incident report from a mobile device and the safety manager views the report.

Field	Entry
ID	UAT-SAF-004, linked to requirement SAF-12
Business outcome	Safety manager observes a new incident in time agreed and has ability to assign action
Actors	Site supervisor, safety manager
Preconditions	Supervisor created a test account for himself on the site. Safety manager is attached to that site.
Steps	1. Supervisor logs into app. 2. Creates new incident. 3. Chooses type/location. 4. Adds photo. 5. Sends. 6. Safety manager logs into dashboard. 7. Opens incident. 8. Assigns corrective action.
Expected result	Incident appears on the dashboard with photo, location and time; assignee receives a notification
Evidence	Screenshots of both views, notification record
Priority	High

Notice what is not included: field labels, button titles and database statuses. Those are best left for QA tester scripts. When building scenarios for construction or fit-out projects it's useful to be familiar with the model-based workflows your users are already undertaking, such as what BIM looks like in construction, so your scenarios speak their language and follow their workflow sequence.

Add negative scenarios and edge cases that actual users encounter: losing connection halfway through a submission, a user without proper authorization, trying to enter a duplicate record, system slowdown during month-end crush. Have at least one scenario per acceptance criterion, and maintain a traceability matrix so that you do not lose track of anything.

Entry criteria: when UAT may start

Entry criteria are conditions that must be met before UAT starts. If they are not met, you do not start. Starting too early is a waste of tester goodwill.

One includes in-scope stories that passed QA, release-candidate build has been deployed, test data has been loaded and verified, critical/high severity QA defects have been fixed, test cases have been reviewed and signed off by business stakeholders, testers have access and credentials, and rollback procedure has been documented and verified. While another mentions a stable production-like environment and reviewed scenarios.

Create checklist with owner and yes/no for each line item. UAT lead signs off in writing prior to day 1.

Exit criteria and the sign-off decision

Exit criteria state what needs to be true for the cycle to be complete and ready for sign-off. Ensure they are measurable. Example thresholds found in published templates: 100% of test cases executed, at least 95% pass rate, no open critical or high defects, medium defects triaged, formal sign-off and UAT summary report distributed. Another suggested passed performance and security checks and recorded business-owner sign-off.

These are examples, not hard-coded values. Agree thresholds that make sense with the approver based on the expense of failure. A payroll run and an internal wiki do not deserve the same standard. For systems where downtime is costly, a high pass percentage and zero open critical defects should be a reasonable minimum.

Sign-off needs to be documented. The sign-off document formally closes testing, notes that all required testing was executed and reviewed and the software is accepted for release, even on the smallest of projects. You should have three options: accepted, rejected, or conditionally accepted with documented exceptions and owners.

Defect handling during UAT

Agree the rules before the first defect arrives.

Severity scale. Provide definitions of critical, high, medium and low in terms of the business. Critical means a core process did not complete and there is no workaround.
Triage. Look through new results each day with product and QA. Determine if each item is a defect, misunderstanding, or change request.
Routing. Defects are routed to the delivery team. Change requests are routed to change control, not added to the UAT backlog.
Retest. After they're corrected, retest fixes and verify they do not create new problems .
Waivers. A known defect may ship only if the approver records a waiver.
Reporting. Note pass, fail or blocked results. Create a closure report detailing what was run and the results .

The coordination steps are easy to articulate: define scope, assign responsibilities, author business scenarios, set up the environment, brief testers, execute scenarios, analyze failures with product and QA, retest, and finally get the approver to review defects and documented exceptions before logging their acceptance, rejection or conditional acceptance.

Schedule and contractual windows

A UAT schedule consists of four blocks: prep, execution, retest cycles, and sign-off. Prep covers scenarios, data and training. Build in buffer for at least one retest cycle. Plans that allow for only one pass have the highest probability of failing on time.

When you purchase software from a supplier, the contract typically defines the window. One definition of terms for contracts states that the typical progression is that the vendor will notify the customer to begin testing. The customer will execute a defined test plan against the software within a defined window, often 15-30 business days. At the conclusion of testing, the customer will provide a written acceptance or written notice of nonconformity. It goes on to state that often, after reported defects are presented to the vendor, the vendor will have a cure period. This cycle will repeat itself a finite number of times. Silence can constitute acceptance. Your UAT plan must operate within those parameters, so read the clause before you establish the schedule. Have your legal counsel confirm how the clause applies to you.

Site acceptance testing: the on-site step before UAT

A lot of people who search for a site acceptance test plan work on projects where software is used to control or monitor physical equipment. In these cases SAT and UAT are two phases of a single path to acceptance.

A site acceptance test is used to confirm that a system satisfies customer requirements. Typically, it occurs at the customer's location following installation and factory acceptance test. This test verifies the installed system in actual operating conditions, after it has been transported to the location, installed, wired, connected to the network and other systems, and attached to utility interfaces. Evaluation occurs against the approved functional design, contract specifications and relevant standards.

The difference in practice:

	Site acceptance test (SAT)	User acceptance test (UAT)
Question	Does the installed system meet the contract specification?	Can our people run the operation with it?
Led by	The provider or integrator, witnessed by the customer	End users and business owners
Where	On site, on installed equipment	Production or production-like environment
Typical checks	Installation, loop and communication checks, functional, safety, integration, performance and redundancy	Business workflows, roles, reports, handover procedures
Output	Signed SAT report	Signed acceptance

A SAT plan should focus on the what that could not be tested at the factory or what may have changed during transport and installation: installation, communication, functional, safety, integration, performance and redundancy checks completed with evidence such as inspection records, startup records and signed report.

Example SAT checks for monitoring and building systems

For a monitoring or building-management deployment, a SAT plan typically lists:

Every sensor and controller present, powered and reporting to the platform.
Confirmation at the device that a value is the same as it displays.
Alarm generation, routing and acknowledgement for each defined threshold.
Behaviour when a network link or a controller fails, and recovery afterwards.
Integration points with the BMS, power monitoring and network management systems.
A signed record for each item, with the name of the witness.

Testing connection to UAT is simple: clear SAT first. Do not ask operators to assess dashboards filled with unverified data. Then do UAT on live shifts with your operations team. Can they see an alarm? Can they acknowledge, escalate and close it out while on the job? If you haven't already, read our article on why monitoring teams should be involved day one of mobilisation for why operators should help design both tests. For teams with on-site staff, health and safety requirements for data centre construction and operations will be the context for safety-related test cases.

Perspective: acceptance is where reliability gets decided

We make software for environments where undetected failure is expensive: data centres, smart buildings, safety instrumented systems. In that work acceptance testing isn't a box-ticking exercise at the end. It's the last opportunity for the people operating the facility to say what they really want.

We believe the best acceptance plans are written early, alongside the requirements. As we blend BMS, PMS and NMS components, we want the operators' scenarios at the table while the design is still fluid. After all, a gap found then only costs hours, not weeks. It's also why we coordinate SAT on installed systems with UAT driven by the operations team.

Acceptance criteria capture the 99.9% uptime SLA we design for. Scenarios should be testable. Name the scenarios, name the thresholds, name the approver. Then have some meaning when it's time to sign off.

Harry

Common mistakes to avoid

Treating UAT like extra QA. Business testers decide fitness for work, not code quality.

Don't have entry criteria. A flaky build incinerates tester trust within the first two days.
Vague exit criteria. “Mostly working” is not a decision.
Unwritten exclusions. They return as defects in week two.
No named approver. Acceptance by committee becomes acceptance by default.
Skipping retests. A fix can break a neighbouring process.

Plan acceptance with the people who build for critical infrastructure

Whether your project is centred around datacenter management, telemetry build, BMS / PMS integration or legacy modernisation, we can assist you in defining acceptance criteria up-front, executing SAT on installed systems and supporting your teams through UAT. We have successfully completed over 250 projects. Our delivery models range from dedicated teams to staff augmentation.

Begin with our BMS and PMS integration services, learn how we handle legacy modernisation or speak to PODTECH about your acceptance strategy.

FAQ

What is the difference between a UAT plan and a UAT test case?

The plan is the master document: scope, roles, environment, criteria, schedule, defect rules and sign-off. A test case or scenario is one business workflow that the plan schedules and assigns. The plan lists the scenarios and defines rules for executing them.

Is site acceptance testing the same as user acceptance testing?

No. Site Acceptance Testing (SAT) is focussed on checking the installed system against the contract specification at site and is normally led by the provider. UAT is focussed on determining whether the system works for real operations and is led by end users. On projects involving physical equipment SAT would normally come before UAT.

Who should sign off a UAT plan?

Someone with stakeholder authority to accept the solution and residual risks. Typically the business owner of the process under development rather than the project manager or project delivery team. Signatory name should be recorded on the plan prior to testing commencement. Signature should be obtained in writing.

How long should UAT take?

It depends on the project scope and risk involved. Many contracts specify a set period of time for testing, often between 15 and 30 business days. Your testing schedule should allow time for at least one retest cycle. Review your contract acceptance clause before committing to fixed dates.

Can I reuse a UAT plan template?

Yes. Templates provide headings for you, but you still need to input your own thresholds instead of the template examples, write your own scenarios from your actual workflows, and enter names of your own testers and approver. If a plan contains template placeholders it should set off alarm bells.