User Acceptance Testing: UAT Plan, Test Cases, and Sign-Off Criteria

User acceptance testing is the last controlled business check before a custom software release goes live. Done well, it tells sponsors whether real users can complete real work with the planned scope, data, roles, policies, and business rules; done poorly, it becomes a late bug hunt with no clear owner for launch decisions.

What user acceptance testing means in plain English

The UAT meaning is simple: authorized users or business representatives validate that the product can support real work before release. User acceptance testing checks business fit, not code quality in isolation. It asks whether agreed workflows, roles, rules, data, reports, permissions, and exceptions behave in a way the business can accept.

The phrase UAT testing is common, although redundant. In practice, teams use it to describe the same activity: business-side validation near the end of the delivery lifecycle.

UAT is different from earlier testing stages:

• System testing verifies that the application works as a complete system against technical and functional specifications.
• Integration testing verifies that connected systems exchange data correctly.
• Regression testing checks that new changes did not break existing behavior.
• Internal QA testing searches for defects before business users spend time on the release candidate.
• UAT confirms whether the business can accept the release for its intended use.

TestRail's 2026 UAT guide places UAT near the end of the lifecycle, after unit, system, integration, and regression testing, with real target users validating the software in realistic scenarios. That timing matters because UAT is not meant to discover every defect. It is meant to answer a business release question: can this version go live under agreed conditions?

For custom software, that answer depends on more than screen behavior. Users may need to validate approval chains, migrated records, pricing policies, reporting rules, permissions, audit trails, and exception paths. If those business rules fail, a technically stable product can still be unfit for launch.

When UAT is ready to start

UAT should start after the product has passed internal QA, integration checks, major defect fixes, release-note review, stable test data preparation, and environment setup. It should not be the first serious test cycle. If business testers receive unstable software, they will spend their limited time finding technical faults instead of validating release readiness.

Use entry criteria before opening the UAT window. At a minimum, confirm that these items are in place:

• Scope for the release is frozen, or any pending change is outside the UAT decision.
• Requirements, user stories, or acceptance criteria are approved and accessible.
• Internal QA has completed planned test cycles for the release candidate.
• System, integration, and regression checks are complete enough for business validation.
• Critical known defects are fixed, or documented as accepted constraints.
• The UAT environment is production-like enough to make results meaningful.
• Test data is stable, realistic, and mapped to the roles being tested.
• Business testers are available and understand their assigned workflows.
• Release notes explain what changed, what is excluded, and what is already known.
• A defect list exists before UAT starts, so testers do not rediscover known issues.

Do not use UAT as a substitute for QA. Business users should not be asked to find broken APIs, missing validations, or repeatable technical defects that internal testing should have caught. For a deeper view of test process discipline, see this guide to quality assurance software testing practices.

If readiness is weak, pause or narrow the UAT scope. Starting anyway usually creates noisy feedback, low trust, and pressure to sign off on a release nobody has truly validated.

How to build a practical UAT test plan

A UAT test plan should act as a release-control document. It defines what will be tested, who can approve results, where testing happens, which data will be used, how defects move through triage, and what conditions must be met before sign-off. A useful plan prevents scope debates during the last week.

A UAT test plan is not a ceremonial template. It should help the release team make decisions quickly when a defect appears, a tester is absent, test data fails, or a business owner disputes whether a result is acceptable.

Atlassian's Jira UAT template describes a UAT plan as a structured document for recording and organizing results and comparing expected outcomes with actual outcomes. That comparison is the center of the plan: every case should produce evidence, not impressions.

For teams releasing custom software, the plan is easier to run when Business Analysis, QA, and Project Management work from the same release scope before UAT begins. That prevents a common failure pattern: QA tests one interpretation, users test another, and sponsors receive conflicting status reports.

Keep the plan short enough that people will use it. A concise plan with named owners and decision rules beats a long document that nobody opens during triage.

Writing UAT test cases that mirror real work

UAT test cases should follow business scenarios, not isolated screen clicks. Each case should map to a requirement, user story, or acceptance criteria and prove that a person in a defined role can complete a meaningful task. Weak cases create false confidence because they pass happy paths while missing policy and workflow exceptions.

Atlassian's acceptance criteria guide defines acceptance criteria as the conditions a task or product must satisfy to be accepted. In UAT, those conditions should become scenario-based cases that business testers can execute and approve.

PractiTest's UAT explainer also points to practical planning habits: define acceptance criteria early, build scenarios from real business processes, select test data, and involve users. Those habits make UAT test cases more reliable because they connect testing back to business operations.

Sample UAT test case format

Use a consistent format so results are easy to compare across testers and workflows:

• Requirement or story ID
• Persona or role
• Business scenario
• Preconditions
• Test data
• Test steps
• Expected result
• Actual result
• Status: not run, pass, fail, or blocked
• Defect ID, if applicable
• Retest result, if applicable
• Approver or business reviewer

A strong test case is specific enough to reproduce but not so scripted that it ignores business judgment. For example, do not write only: user creates invoice. Write the scenario around the real rule: billing manager creates a prorated invoice after a mid-cycle subscription upgrade, verifies tax and discount treatment, sends it to the customer, and confirms the accounting export.

Brief user acceptance testing examples

These user acceptance testing examples show how cases should reflect business risk rather than generic navigation.

SaaS subscription billing: An account admin upgrades from a standard plan to an enterprise plan mid-cycle. The case verifies prorated charges, invoice line items, seat limits, payment status, customer notification, subscription status, and audit log entry. A pass means finance and customer success can trust the billing outcome.

Healthcare appointment scheduling: A receptionist books, reschedules, and cancels an appointment for a returning patient. The case verifies provider availability, patient confirmation, calendar updates, cancellation rules, and access by authorized staff only. A failure may create operational and compliance risk even if the calendar screen appears functional.

B2B portal permissions: A supplier admin invites a read-only user to a customer portal. The case verifies that the user can view allowed purchase orders and invoice status but cannot change payment details, invite users, view restricted pricing, or access another supplier's data. A pass confirms that role permissions support the business policy.

Good UAT test cases create evidence for acceptance. They should tell a sponsor which business flows work, which do not, and which residual risks are being accepted.

Defect triage and launch blockers during UAT

During UAT, every issue needs two labels: technical severity and business priority. Severity describes system impact; priority describes release decision impact. A low-severity display issue on an invoice may block launch if it creates billing disputes, while a higher-severity defect in unused scope may be deferred with approval.

Treat severity and priority separately:

• Severity answers: how badly does the system fail?
• Business priority answers: how much does this issue affect release readiness?

This distinction prevents noisy triage. A spelling error on an admin-only page and an incorrect tax calculation should not compete as equal defects simply because both are open.

Common UAT launch blockers include:

• A critical-path workflow cannot be completed by the intended role.
• A defect creates money, data, privacy, or compliance risk.
• Role permissions allow too much access or block required access.
• Migrated data is incomplete, duplicated, mismatched, or unreliable.
• A high-volume workflow is too slow for normal business use.
• Reporting, audit trail, or export output is unusable for operations.
• A required integration fails in a business-critical scenario.
• The named sign-off owner is absent or refuses to accept risk.

Run triage with enough authority in the room: product owner, business sponsor or delegate, QA lead, project manager, and technical lead. The group should decide whether each issue is a blocker, a fix-before-release item, or a deferred defect.

Medium and low defects can be accepted only when the acceptance is explicit. Document the workaround, business owner, target fix release, user impact, and approval. Without those details, deferred issues become post-launch disputes.

Avoid averaging defect counts. One payment, permission, or migration issue can outweigh dozens of cosmetic defects. UAT status should focus on release risk, not only pass percentage.

Sign-off criteria for user acceptance testing

Sign-off should be based on named exit criteria, not a vague comment that the product looks good. The business owner should confirm what was tested, which defects remain, which risks are accepted, and what follow-up release will handle deferred fixes. Clear criteria reduce disputes after go-live.

Useful UAT exit criteria can include:

• All critical-path UAT test cases have been executed.
• The agreed pass threshold has been met.
• No critical or high-priority launch-blocking defects remain open.
• Fixed defects have been retested and passed.
• Known issues are documented with workaround, owner, and target fix release.
• UAT summary report is complete and shared with sponsors.
• Named business owner has signed off on the release decision.

A practical sign-off template can stay short:

• Release name and version:
• UAT dates and environment:
• Scope tested:
• Scope excluded:
• Total cases planned, executed, passed, failed, and blocked:
• Open critical or high-priority defects:
• Accepted known issues:
• Deferred fixes and planned release:
• Business risks accepted:
• Approver name and role:
• Decision: approve, approve with conditions, or reject:

If the decision is approve with conditions, write the conditions plainly. For example: release is approved only if the payment export fix passes retest by 3 p.m. on the release date. Conditional approval without a deadline or owner is only delayed confusion.

Vladimir Terekhov

Co-founder and CEO at Attract Group