User acceptance testing checklist for Qatar software launches

A user acceptance testing checklist helps businesses in Qatar confirm that new software works for the people who will use it before go-live. UAT is not the developer's testing. It is your own staff running real tasks, in Arabic and English, with real roles, payments and data, and signing off against the written scope. This guide gives a practical checklist and explains who should do what.

What is user acceptance testing, and who should do it?

User acceptance testing is the final check where the business, not the developer, confirms that the system supports its work. It should be done by the people who will use the system every day, led by one person who owns the sign-off.

The vendor's QA team tests that the software matches the specification: buttons work, calculations are correct, nothing crashes. UAT asks a different question: can a dispatcher, a cashier or an accountant do their actual job with it? Only your staff can answer that. Pick testers from each role, including at least one sceptic, and give them protected time. UAT squeezed between normal duties tends to be rushed.

When should UAT start?

UAT starts after the vendor's own testing has passed on a stable staging environment, and before go-live. It should happen for every release, not only the first one.

Sprint demos are not UAT. A demo shows progress and invites feedback. UAT is a structured round where testers follow written cases and record results. On phased projects, run a short UAT for each phase, so problems are found while the scope is still small.

What should a UAT checklist cover?

Cover the full working day of every role, not just the happy path. Use this checklist as a starting point and add your own processes:

• Every user role can log in and sees only what it should
• Each core process runs from start to finish, for example order to invoice or booking to payment
• Approvals, rejections and returns work, not just the normal flow
• Calculations match what your finance team expects: prices, discounts, totals and rounding in QAR
• Printed and emailed documents are correct in both languages: invoices, receipts, delivery notes and reports
• Notifications reach the right people by email, SMS or WhatsApp
• Integrations send and receive the right data, including what happens when the other system is offline
• Reports match the numbers in the underlying records
• Data migrated from the old system is complete and readable
• The system is fast enough with realistic data volumes
• Mobile screens work on the phones your staff and customers actually use
• Help text, error messages and labels make sense to someone new

Which Qatar-specific cases should you test?

Test the local details that generic test plans miss. They are small individually and very visible to users when wrong.

• Arabic and English on every screen, with right-to-left layout, mirrored icons and mixed Arabic-English text displayed in the right order
• Amounts in QAR, including how dirhams, rounding and totals display
• QPay payments with NAPS debit cards, including returning from the QPay page, cancelled payments and refunds
• Visa, Mastercard and Apple Pay payments where offered
• Phone numbers in the Qatari format with the +974 country code
• Qatar ID numbers and passport numbers in registration forms
• Addresses using zone, street and building numbers, or a map pin
• Working days from Sunday to Thursday in schedules, delivery dates and due-date calculations
• Public holidays and Ramadan working hours in booking and scheduling features
• Invoices with a tax field that stays at zero while no VAT applies, and can be enabled later

How do you write good UAT test cases?

Write each case as a real task with a clear expected result, in the language your testers use. A good case names the role, the starting data, the steps and what should happen.

For example, a logistics company in Qatar testing a new driver app might write: as a driver, open today's trips, start the first trip, mark a delivery as completed with a photo and signature while offline, then reconnect and check that the dispatcher sees the delivery as completed with the correct time. That single case tests the app, offline sync, the dashboard and the timestamp.

Test data matters as much as the cases. Use realistic customers, products, prices and documents, including awkward ones: long Arabic names, customers with two branches, orders with returns. If you test with copies of live data, mask personal details first, as you would for any system that holds personal data.

Keep the cases in a shared tracker, not in emails. Each case should show who ran it, when, the result and any defect raised.

How should defects be logged and prioritised?

Log every defect with steps to reproduce, the expected result, the actual result and a screenshot. Agree on severity levels before UAT starts, so arguments about priority do not slow down go-live.

• Blocker: a core process cannot be completed, so go-live waits
• Major: a process works with a painful workaround, fixed before go-live or with an agreed plan
• Minor: cosmetic or rare issues, scheduled into a later sprint
• Change request: the system works as specified, but the business now wants something different

Agree the go-live criteria in writing before testing begins, so sign-off is a check rather than a debate:

• Every test case has been run at least once, with results recorded
• No open blockers, and every major defect is fixed or has an agreed workaround and date
• Data migration has been checked by the people who own the data
• Users have been trained, and a support contact is named for the first days
• A rollback or fallback plan exists if something serious appears after launch
• The business owner of the system has signed off in writing

Separating defects from change requests is important. Both are valid. Mixing them hides the real quality of the build and blurs the budget.

What drives UAT effort, and where are the trade-offs?

UAT effort grows with the number of roles, processes, integrations, languages and devices. A bilingual system with payments and three integrations needs far more cases than an internal tool used by one team.

The main trade-off is depth against time. Testing every combination is impossible, so prioritise processes that handle money, legal documents and customer-facing screens. For regression testing across releases, automated tests run by the vendor reduce the manual load, so your staff can focus on new features and real-world judgement. Our software testing services for Qatar cover both the vendor-side testing and support for your UAT.

How is testing usually run with an outside development team?

Testing runs through the whole project, not only at the end. We start with video-call workshops and a written scope, which becomes the basis for acceptance criteria. A named lead engineer runs delivery in two-week sprints, with a demo every sprint, and our QA engineers test each feature as it is built.

Before each phased release, we prepare a staging environment, test data and a draft UAT checklist for your team. Our working hours overlap your full working day, so defects found in your morning can be answered the same day, Sunday to Thursday. After sign-off, the release goes live, and at handover the code and cloud accounts are registered to you. Read more about our quality assurance services, or see how we test mobile apps for Qatari companies.

Frequently asked questions

How long should UAT take?

Long enough to run every case at least once and re-test the fixes. Plan it into the schedule from the start rather than squeezing it before a fixed launch date.

Can the vendor do UAT for us?

The vendor can prepare cases, data and environments, but your staff must run them. Acceptance means the business confirms the system fits its work.

What if we find new requirements during UAT?

Log them as change requests, separate from defects. Decide which are needed for go-live and which can follow in a later phase.

If you are preparing for a launch and want help with test planning or UAT, talk to us.