User Acceptance Testing (UAT): A Guide for Software Buyers

User acceptance testing (UAT) is the final check in which the people who will use the software run real business scenarios and decide whether to accept it. It is not a second round of QA: by UAT, the vendor should already have tested that the software works. UAT tests whether it fits the job, against acceptance criteria agreed before the build started.

If you want help preparing or supporting UAT, see how RAITHub would test this below.

What is user acceptance testing?

The ISTQB glossary defines user acceptance testing as acceptance testing performed by intended users to determine whether a system satisfies their needs and is ready for operational use. Acceptance testing in general is formal testing against user needs, requirements and business processes, to decide whether to accept the system.

For a buyer, the practical meaning is contractual as much as technical. UAT is usually the gate between "the vendor says it is done" and "we accept it, pay the milestone and go live". That is why it needs written criteria, named testers and a clear sign-off.

How is UAT different from QA testing?

	QA and system testing	User acceptance testing
Question it answers	Does the software work as specified?	Does it do our job well enough to go live?
Who runs it	Testers and developers, usually on the vendor side	Real users or their representatives, on the buyer side
What it is tested against	Requirements, designs and test cases	Business scenarios and agreed acceptance criteria
When it happens	Throughout the build	At the end of a release or milestone
What failure means	A bug to fix	Either a bug, or a gap between what was specified and what is needed
Typical output	Bug reports and test results	A signed acceptance or a list of blockers

If your users are finding crashes and broken buttons in UAT, QA did not happen. Stop UAT, send it back and ask what testing was done; the pre-launch QA checklist is a fair minimum to expect first.

Who should run UAT?

The people who will do the work in the software, not the people who bought it.

• A UAT lead on the buyer side who owns the plan, the schedule and the sign-off decision.
• Two to five testers per user role. A warehouse picker, a finance clerk and an admin will each find different gaps.
• A vendor contact who answers questions, triages reports and ships fixes, but does not run the tests.

Give testers protected time. UAT squeezed between their normal work becomes ten minutes of clicking and a signature.

How do you write acceptance criteria?

Write them before the build, per feature, as observable outcomes a user can check. A common format is Given / When / Then, from the Gherkin language described in Cucumber's Gherkin reference. You do not need Cucumber to use it; the structure alone makes criteria testable.

Feature: Approving supplier invoices

  Scenario: Finance manager approves an invoice within their limit
    Given an invoice for 4,800 USD from an approved supplier
    And the finance manager's approval limit is 5,000 USD
    When the finance manager approves the invoice
    Then the invoice status is "Approved"
    And the supplier is scheduled for payment on the next payment run
    And the approval appears in the audit log with the manager's name

  Scenario: Invoice above the limit needs a second approver
    Given an invoice for 7,200 USD
    When the finance manager approves the invoice
    Then the invoice status is "Awaiting second approval"
    And the finance director is notified

Good criteria share three traits: a user can check them without reading code, they include the rule as well as the happy path, and they say what should be recorded or sent. "Invoices can be approved" is a wish, not a criterion.

What are the steps of a UAT plan?

1. Agree entry criteria. UAT starts only when the vendor's QA is complete, known bugs are listed, and the UAT environment and data are ready.
2. Write scenarios from real work. Turn last month's actual cases into test scenarios: a real order, a real refund, a real month-end.
3. Prepare data and accounts. One account per role, realistic records, and anonymised copies of production data where your data rules allow.
4. Brief the testers. Thirty minutes on the scenarios, how to report a problem and what counts as a blocker.
5. Run the scenarios in a fixed window, typically one to two weeks for a release of moderate size.
6. Report and triage daily. Each report is a bug, a change request or a training issue. The bug report template keeps reports fixable.
7. Retest fixes and rerun the scenarios they touch.
8. Decide against exit criteria and sign off, sign off with listed exceptions, or reject.

What should UAT sign-off mean?

Sign-off is a business decision with a written record. Agree its meaning in the contract or statement of work, not at the end.

• Exit criteria: for example, all scenarios run; no open blocker or critical issues; every open minor issue has an owner and a date.
• Severity definitions agreed in advance, so "blocker" is not argued over in the last week.
• Change requests separated from bugs. If the software does what was specified but not what you need, that is a change, and it should be priced and planned as one.
• A named signatory and a dated record of what was accepted.

This is general information about structuring acceptance; if acceptance triggers payments or legal obligations, confirm the wording with your adviser.

What are the common UAT mistakes?

• Using UAT as QA. Users should not be the first people to find that the login breaks; QA as a service is one way to get the build tested independently first.
• No acceptance criteria. Without them, every opinion is a defect and nothing can be signed.
• Testing with fake, tidy data. Real data has duplicates, odd characters and half-finished records.
• Only the managers test. The person who buys rarely does the daily work.
• No time box. UAT drifts for months and the launch date with it.
• Treating every gap as a bug. Some are change requests. Mixing the two poisons the relationship with the vendor.

Buy, build or hire?

Option	What you get	Choose this when	Watch out for
A tool or SaaS testing platform	Test management or UAT tools to track scenarios, results and sign-off	You have many testers or regulated evidence needs	A tool tracks UAT; your users still have to do it
Freelancers or crowdtesting	Outside testers running scripted scenarios	You need extra hands for the vendor-side QA before UAT	Outsiders cannot judge business fit; that part stays with your users
An in-house QA hire	A tester who prepares scenarios, data and triage for your users	You accept software from vendors regularly	One person struggles to cover QA and UAT coordination at once
A managed QAaaS team	Independent QA before UAT, plus UAT preparation and triage support	You want the build verified independently before your users spend time on it	The team supports UAT; your users still make the acceptance decision

Why RAITHub for UAT support?

• QA before UAT, not instead of it. RAITHub's QA as a service includes manual and exploratory testing and UAT support, so users meet software that has already been tested.
• Independent of whoever built it. RAITHub can test software another vendor built and report what it finds plainly.
• Criteria that can be tested. RAITHub engineers write acceptance criteria and tests on their own builds; on platforms like PropDesk the automated suite has 1,024 tests.

When you don't need us

• Your vendor's QA is strong and documented, and your team has run UAT before. Use the plan above.
• The software is off the shelf with no customisation. A trial with your own scenarios is your UAT.

How RAITHub would test this

• Scope: independent QA of the release before UAT; turning your real cases into UAT scenarios and acceptance criteria; preparing roles, accounts and test data; daily triage of UAT reports into bugs, change requests and training issues; retesting fixes.
• How you buy it: a fixed-price one-off audit before acceptance, a monthly QA plan for ongoing releases, or a dedicated QA team that RAITHub manages and bills monthly. No staff augmentation.
• Timeline: fixed in the written quote around your UAT window.
• What you receive: the QA report, UAT scenarios, triage log and a sign-off pack, under an NDA as standard. See manual testing and UAT support.
• Next step: a free 15-minute audit call, then a fixed written quote.

Choose a QA audit on the contact form to check a release before your users see it.

Last reviewed: 7 October 2026.

Frequently asked questions

Who is responsible for user acceptance testing?

The buyer. Real users or their representatives run UAT and decide whether to accept the software. The vendor supports it by answering questions, fixing issues and retesting.

How long does UAT take?

For a release of moderate size, one to two weeks of testing is common, plus time to fix and retest. It depends on the number of roles, scenarios and how ready the software is when UAT starts.

What is the difference between UAT and beta testing?

UAT is a formal acceptance check against agreed criteria, usually before go-live. Beta testing releases the product to a wider group of real users to gather feedback, often after it is accepted.

What happens if UAT fails?

Blockers are fixed and the affected scenarios rerun. Gaps between the specification and what users need are logged as change requests. Acceptance waits until the exit criteria are met.

Can UAT be automated?

The scenarios can be automated as regression tests later, but the acceptance decision cannot. UAT exists so people who do the work can judge whether the software fits it.

Can RAITHub run UAT for us?

RAITHub prepares and supports UAT: scenarios, data, triage and retesting, plus independent QA beforehand. The acceptance decision stays with your users.