A user acceptance testing checklist helps your own staff confirm that new software supports real business work before it goes live. For companies in the UAE, that means checking everyday processes in English and Arabic, prices in AED, 5% VAT on invoices, local payment methods and the Monday to Friday working week. This guide explains who should test, what to cover, how to report defects and when to sign off.
What is user acceptance testing and who should do it?
User acceptance testing, or UAT, is the final check where the people who will use the software confirm it does what the business needs. It should be done by staff from the business, not by the developers who built it.
Developers and QA engineers test that the software works as specified. UAT asks a different question: does it work for us? A sales coordinator, a branch supervisor or an accountant will notice problems a tester never sees, such as a report that lacks the column the manager needs, or a step that adds a minute to every order. Choose testers who know the process well, give them time away from their normal work, and include at least one person from each role that will use the system.
When should UAT happen in a project?
UAT should happen before every significant release, not only once at the end. Short rounds after each phase find problems while they are still cheap to fix.
In projects run in sprints, business users already see the software at each demo. UAT is the more formal step: a set period where users work through prepared scenarios in a test environment that mirrors production, record what they find, and confirm whether the release can go live. Plan for it in the schedule. A common mistake is leaving one rushed week for UAT just before a fixed launch date, when nobody has time to fix what testers find.
Prepare the test environment properly before testers start. It should hold realistic data, connect to the test modes of your payment gateway and messaging services, and send emails and SMS only to test addresses or numbers. Give every tester a login for each role they will play, a short briefing on the scenarios, and one place to record results. A half-ready environment wastes testers' time and erodes their confidence in the new system.
What should a UAT checklist cover?
A UAT checklist should cover complete business processes from start to finish, plus the local details that generic test plans miss. Use this list as a starting point and adapt it to your system.
- Every main business process end to end, such as quote to invoice, booking to payment or order to delivery
- Each user role, checking that people see what they need and nothing they should not
- Screens, messages, emails and PDFs in English and Arabic, with right-to-left layouts
- Prices and totals in AED, with rounding that matches your accounting system
- Tax invoices showing the correct TRN, invoice numbering and 5% VAT, checked by your finance team
- Payments, refunds and failed payments using the gateway's test mode
- Working days, deadlines and reminders based on a Monday to Friday week and UAE public holidays
- Notifications by SMS, email or WhatsApp reaching the right person
- Reports and exports matching figures from your current system
- Data migrated from the old system, checked against a sample of real records
- Behaviour on the phones, tablets and browsers your staff and customers actually use
- Permissions, password reset and account lockout
How do you write good UAT scenarios?
Write each scenario as a real task with clear steps and an expected result, based on what actually happens in your business. Good scenarios come from daily work, not from the feature list.
A useful scenario names the role, the starting point, the steps and the outcome. For instance: as a branch supervisor, approve a discounted order above the usual limit, and confirm the customer receives an Arabic invoice with the discount and VAT shown correctly. Include awkward cases too: a cancelled order, a customer with two accounts, a refund after month end, a deposit in a foreign currency. The awkward cases are where most real defects hide.
What does UAT look like for a typical company?
For example, a logistics company in Sharjah replacing spreadsheets with a dispatch system and a driver app might ask a dispatcher, two drivers, a customer service agent and an accountant to test. The dispatcher plans a day of deliveries, drivers complete them in the app including a failed delivery and a proof-of-delivery photo, customer service handles a complaint, and the accountant checks that invoices and reports match. Each tester records results against prepared scenarios, and the team meets daily to review defects.
Testing this way exposes problems in handovers between roles, which are invisible when each screen is tested on its own. Our logistics software for the UAE is built to be tested in exactly this kind of end-to-end way.
How should defects be reported and prioritised?
Every defect should be recorded in one shared tool with steps, a screenshot and a severity, so nothing is lost in emails or chat groups. Severity decides what must be fixed before go-live.
- Critical: blocks a core process or produces wrong financial figures, must be fixed before launch
- High: a workaround exists but is slow or risky, usually fixed before launch
- Medium: an inconvenience that does not stop work, scheduled for an early update
- Low: cosmetic issues or suggestions, recorded for a later phase
Separate defects from change requests. If the software does what was agreed but the business now wants something different, that is a change, and it should be estimated and planned rather than squeezed into the release. Agree sign-off criteria before UAT starts, for example no open critical or high defects, so the go-live decision is not a debate.
How is testing usually run in a project with us?
Testing runs through the whole project, and UAT is the last of several layers. Discovery happens in video-call workshops where we agree processes and acceptance criteria, and they are recorded in the written scope.
We deliver in two-week sprints with a demo each time, so business users see progress early. Our quality assurance team runs functional, regression and device testing before each release reaches your testers, which keeps UAT focused on business fit rather than basic bugs. A named lead engineer handles defect triage with your project owner. We can prepare UAT scenarios, set up the test environment and train your testers. At handover, the code, cloud accounts and test documentation are yours.
Should you get outside help with UAT?
Your staff must do the testing, but outside help with planning, test environments and defect management often makes UAT faster and less stressful. The decision depends on the size of the system and on your team's experience.
Cost drivers include the number of processes and roles, how much data must be migrated and verified, the number of devices and browsers, whether Arabic is in scope, and how many test rounds are planned. If you are buying software rather than building it, run UAT anyway: configure the product with your data and test your processes before you sign off. Our software testing services in the UAE page explains the support we offer.
Frequently asked questions
How long should UAT take?
Long enough for testers to complete every scenario and for critical fixes to be retested. Size it to the number of processes and roles, and add time for a second round.
Can automated tests replace UAT?
No. Automated tests confirm that the software behaves as specified. UAT confirms that the specification itself fits the business, which needs human judgement.
Who signs off UAT?
A named business owner, usually the person responsible for the process, signs off once the agreed criteria are met. Keep a written record of the decision.
Should UAT use real customer data?
Prefer anonymised or test data. If real data is needed, limit who can access the test environment and remove the data afterwards.
If you are preparing for a launch and want a structured UAT plan, talk to us about your project.
This guide was researched and drafted with the help of AI tools, then checked for accuracy against our editorial rules. Laws, tax rules and prices change: confirm current requirements with your adviser before you decide.
Working on something similar?
See our Software QA & Testing Services for GCC & US Businesses page, or talk it through with us, with no obligation.