User Acceptance Testing is the step where the client confirms, in a structured way, that the delivered website or app actually does what was agreed. Skipping it produces the worst kind of launch: bugs discovered by real customers, and a dispute about whether the missing behavior was ever in scope.
Most clients we meet have never run a UAT before, so they either click around randomly for an hour or sign off without testing at all. This template fixes that: a short plan, a test case table your team fills during testing, a defect log with severities, and a sign-off page that makes acceptance explicit. It is the same structure we hand to our clients before every delivery since 2014.
How to use this template
- Write test cases from the requirements document, not from the built product: one case per agreed behavior.
- Test with real-world data: real product names, real Arabic text, real phone numbers, on real phones.
- Log every defect with a severity: critical defects block sign-off, cosmetic ones go to a punch list.
- Sign off in writing once exit criteria are met. This protects both sides.
The Full Template: 9 Sections
Document Control
Identifies the project, the build under test, and the document version.
Scope & Objectives
States what this UAT round covers and, just as important, what it doesn't.
Roles & Responsibilities
UAT fails when "someone will test it". Name the testers and the single person empowered to sign.
| Role | Name | Responsibility |
|---|---|---|
| UAT lead (client) | assigns cases, consolidates results, signs off | |
| Testers (client) | execute assigned cases, log defects | |
| Delivery lead (vendor) | triage defects, deliver fixes, retest builds | |
Entry Criteria
Don't start UAT on a build that isn't ready, you'll waste the testers' single most valuable asset: attention.
- Vendor's internal QA completed; no known critical defects open.
- Staging environment live with test accounts for every role.
- Test data loaded (products, sample users, sample orders).
- All agreed features present in the build (no "coming in the next drop" for in-scope items).
Test Environment & Accounts
Testers must know exactly where to test and with which credentials, in one place.
| Item | Value |
|---|---|
| Staging URL / app build | staging.example.com / TestFlight & APK links |
| Admin account | user / pass (test only) |
| Customer account | user / pass (test only) |
| Payment mode | gateway sandbox, test cards documented |
Never test with real customer data or live payment cards.
Test Cases
The heart of the document. One row per agreed behavior, written so a non-technical person can execute it. Duplicate the table per module.
| ID | Scenario | Steps | Expected result | Actual result | Status |
|---|---|---|---|---|---|
| UAT-001 | New customer registration | Open app → Register → fill valid data → submit | Account created, verification SMS received, user lands on home | Pass / Fail | |
| UAT-002 | Order with cash on delivery | Login → add 2 products → checkout → COD → confirm | Order appears in admin dashboard with correct totals; customer gets confirmation | Pass / Fail | |
| UAT-003 | Arabic content rendering | Switch app to Arabic → browse key screens | RTL layout correct, no truncated or mixed-direction text | Pass / Fail | |
Coverage guide: every Must feature from the requirements document needs at least one case, plus the unhappy paths (wrong password, empty cart checkout, expired card).
Defect Log
One shared list, each defect with a severity. Severity is what turns the log into launch decisions.
Critical blocks core flows, no workaround Major feature broken, workaround exists Minor wrong but usable Cosmetic visual polish
| ID | Related case | Description | Severity | Status |
|---|---|---|---|---|
| DEF-001 | UAT-002 | Order total ignores delivery fee in admin view | Major | Open / Fixed / Retested |
Exit Criteria
Defines, before testing starts, what "good enough to launch" means. Prevents both endless UAT and premature sign-off.
- 100% of test cases executed.
- Zero open Critical or Major defects.
- Minor and Cosmetic defects listed in a punch list with an agreed fix date.
- Regression check passed on flows affected by fixes.
Sign-off
The written acceptance. After this, remaining punch-list items are tracked under maintenance, not open scope.
Sample wording: "We confirm that UAT for [project] was executed per this document, exit criteria are met, and the system is accepted for production launch, subject to the attached punch list."
| Name | Role | Signature | Date |
|---|---|---|---|
| Client representative | |||
| Vendor representative |
How much UAT is enough?
For a company website, one focused day with two testers usually covers it. For an app with payments and roles, plan 3 to 5 days across at least two rounds: round one finds the defects, round two verifies the fixes and runs a regression pass on anything the fixes touched. Resist the urge to test only the happy path; most production incidents live in the unhappy paths nobody tried.
One more habit worth keeping: test on the devices your customers actually use. In our market that means mid-range Android phones on mobile data, not the office's flagship phone on Wi-Fi.
Frequently Asked Questions
Who should perform UAT, us or the development company?
The client's team. The vendor already ran its internal QA; UAT exists precisely to check the system against your business expectations with your people. The vendor supports with environments, accounts and fast defect triage.
How is UAT different from QA testing?
QA verifies the software works as specified and is done by the vendor's testers throughout development. UAT verifies the specification itself matched your business need, executed by end users at the end. Both are needed; one does not replace the other.
What if we find a missing feature during UAT?
Check it against the signed requirements document. If it's there, it's a defect and gets fixed. If it isn't, it's a change request, priced and scheduled separately. This distinction is why the requirements document matters so much.
Does Web Pioneer provide UAT support?
Yes. Every delivery includes a staging environment, test accounts, a pre-filled test case list based on your requirements, and defect triage during your UAT window.
Delivering a project soon?
We can review your UAT plan, or run the whole acceptance process with your team.
Download the Word file + free review
Enter your details and the Word file will download instantly, and our team will gladly review your UAT plan for free.
