User Acceptance Testing: How to Check a System Before You Sign Off
User acceptance testing (UAT) is the final check, carried out by your own staff with your own real cases, that a new system does what the business needs before you accept it and pay for it. Prepare test scenarios from the agreed acceptance criteria and from recent real cases, including the awkward ones. Test in a realistic environment with migrated data, log every problem with a severity, agree in advance what must be fixed before go-live, re-test the fixes, and then sign off in writing.
Sign-off usually releases a payment and starts the warranty period. It is the last moment you have real leverage, so it deserves real time.
The short answer
- Your people, your cases. UAT is not the supplier’s testing and not a demonstration.
- Scenarios come from acceptance criteria and real recent cases, exceptions included.
- Test everything a user touches: roles and permissions, Arabic and English, printouts, devices and end-to-end flows.
- Use realistic data, ideally from a trial migration.
- Agree exit criteria before testing starts, such as no critical or high-severity issues open.
- Sign off in writing, listing any accepted issues and the dates they will be fixed.
“Sign-off is the last moment you have real leverage. Test the system with your own messiest cases, not with the supplier’s demo script.” — Abdulqader Wahiba, founder and CEO of ZAWAT
What UAT is, and what it isn’t
The supplier should test its own work before handing it over: checking that each function works, that the code holds together and that nothing old has broken. That is quality assurance, and it is their job.
UAT answers a different question: does this system let our people do their work, in our conditions, with our data? Only your staff can answer it. A polished demonstration on prepared data proves very little; your real cases prove a great deal.
Who tests, and when
Choose the people who will use the system every day, plus the owner of the result. Release them from part of their normal work for the testing period. UAT squeezed into the end of a busy day finds only the obvious problems.
Plan UAT into the schedule from the start, rather than treating it as whatever time is left before launch. How long a software project takes explains why testing is the first thing squeezed when a schedule slips.
Preparing test scenarios
Good scenarios come from two places.
The acceptance criteria agreed in the requirements, written as “given, when, then”. Writing requirements with user stories shows the format. Each criterion becomes at least one test.
Real recent cases, especially the difficult ones: the customer with two delivery addresses, the order paid in instalments, the return after the invoice was issued, the request submitted while the approver was travelling.
Then make sure the scenarios cover:
- Roles and permissions. Log in as each role. Can a storekeeper see salaries? Can a branch manager approve another branch’s request? They should not.
- Arabic and English. Every screen, message, email and PDF in both languages, with correct right-to-left layout, Arabic sorting and search.
- Printouts and documents. Invoices, delivery notes and reports, printed and as PDF.
- Devices. The phones and tablets your staff actually use, not just a desktop browser.
- End-to-end flows. An order through to invoice, payment and accounting entry, including every integration on the way.
- Reports. Totals that reconcile with your own figures.
A simple template is enough:
| Scenario | Role | Steps | Expected result | Pass or fail | Issue number |
|---|---|---|---|---|---|
| Approve a purchase of OMR 450 | Branch manager | Open the request and approve | Status is Approved; storekeeper notified; approval logged | ||
| Try to approve OMR 600 | Branch manager | Open the request | View only; routed to the general manager |
Environment and data
Test in an environment that mirrors the live one: same configuration, same integrations, connected to test versions of external services where they exist. Use realistic data, ideally from a rehearsal of the data migration, so you test with the names, products and balances your staff know. Moving your data into a new system covers those rehearsals.
Testing with invented data hides the problems that real data creates: long Arabic names, unusual characters, old records with missing fields.
Logging issues properly
Use one tracker, shared with the supplier. For each issue, record the steps to reproduce it, what you expected, what happened instead, a screenshot, and a severity:
- Critical: the process cannot be completed, or data is wrong or at risk.
- High: a major function fails, with no reasonable workaround.
- Medium: a function is impaired, but there is a workaround.
- Low: cosmetic issues and suggestions.
Keep new feature requests separate from defects. Both matter, but only defects decide sign-off.
Exit criteria, agreed in advance
Before testing starts, agree what “accepted” means. A common set of criteria:
- all planned scenarios executed;
- no critical or high-severity issues open;
- medium issues listed, each with an agreed fix date;
- data migration rehearsal reconciled;
- key users trained.
Agreeing this in advance keeps sign-off from becoming a negotiation under deadline pressure. Abdulqader Wahiba recommends writing the criteria down before the build starts, so that sign-off is a check against an agreement rather than a debate. The contract’s acceptance clause should point to the same criteria, as choosing a software partner in Oman recommends.
Re-testing and sign-off
When fixes arrive, re-test the failed scenarios and repeat a sample of passed ones, because fixes can break other things. Then sign off in writing: what was tested, the result, the accepted open issues and their fix dates, and the start of the warranty period. Keep the test records; they are useful evidence if a problem appears later.
Common mistakes
- Testing only the happy path. The exceptions are where systems fail.
- Managers testing instead of users. Managers know the process as designed; users know it as it runs.
- Dummy data. It hides real-world problems.
- No time set aside. Testing done in spare minutes finds only obvious faults.
- Signing off under pressure. A launch date is not a reason to accept a critical defect.
- Skipping the Arabic interface. Bilingual systems need to be tested in both languages, by people who read both.
Frequently asked questions
What is the difference between UAT and the supplier’s testing? The supplier’s testing checks that the software works as built. UAT checks that it works for your business, with your people, cases and data. You need both.
How long should user acceptance testing take? It depends on the size of the system and the number of scenarios. For a focused first version it is often a matter of weeks rather than days. Plan it into the schedule, with staff time released for it.
Can we go live with known issues? Yes, if they are minor, have workarounds, and are listed in the sign-off with fix dates. Going live with critical or high-severity issues usually costs more than a short delay.
What if we find problems after sign-off? Defects in what was delivered should be covered by the warranty period agreed in the contract. After that, they fall under the support agreement. What a maintenance and support agreement should cover explains the difference.
Who should sign off? The owner of the result, on the advice of the staff who tested. Sign-off is a business decision, not a technical one.
Sources: Agile Alliance — Given-When-Then
About to accept a new system, or planning one? ZAWAT builds custom software with acceptance criteria agreed up front and tested with your own cases. Book a call.