User Acceptance Testing Checklist: How to Test a Custom Business System Before Launch

A custom business system may look ready in a demo, but the real test is whether your team can use it correctly on a normal working day. Before launching a web app, portal, CRM, ERP module, approval system, or internal dashboard, business owners and managers need a clear User Acceptance Testing process. Without it, small issues in forms, permissions, Arabic content, approvals, or reports can turn into daily operational problems after go-live.

User Acceptance Testing, often called UAT, is the stage where actual business users test the system against real work scenarios. It is not only a technical quality check. It is a business readiness check. The goal is simple: confirm that the system supports your workflows before customers, employees, suppliers, or management depend on it.

1. Prepare Real Business Scenarios, Not Generic Test Cases

The most useful UAT starts with real workflows from your company. Avoid testing only with simple examples such as “create customer” or “submit request.” These tests may pass while the real process still fails.

Build your checklist around everyday situations such as:

• A sales employee creating a new lead and assigning it to a branch
• A customer submitting a service request in Arabic
• A manager approving a purchase request from a mobile device
• A finance user reviewing invoices and exporting a report
• An operations team member updating order status after delivery
• An HR user uploading employee documents and sending them for approval

For each scenario, define the expected result in plain language. For example: “When a branch manager approves the request, the finance team should receive a notification and the request status should change to Approved.” This helps non-technical users test confidently.

Use real but safe sample data. Do not use live customer records unless they are properly anonymized. Include realistic Saudi and Gulf details where relevant, such as mobile numbers, national ID or commercial registration formats, Arabic names, Hijri or Gregorian date needs, VAT fields, cities, regions, and branch structures.

2. Test Roles, Permissions, and Approval Flows Carefully

Many custom systems fail at launch not because the main feature is broken, but because the wrong person can see, edit, approve, or delete the wrong information. For Saudi and Gulf businesses with multiple branches, departments, or management levels, role testing is essential.

Create a list of all user roles before UAT begins. Common examples include:

• Admin
• Department manager
• Branch manager
• Finance user
• Sales user
• Customer service user
• External customer or supplier
• Read-only executive user

Then test what each role can and cannot do. A sales user may need to create customers but not view finance reports. A branch manager may approve only requests from their branch. An executive may need access to dashboards without the ability to change transactions.

Approval workflows need extra attention. Test the full journey from submission to final approval or rejection. Include these checks:

• Does the request go to the correct approver?
• What happens if the first approver rejects it?
• Can users add comments or attachments?
• Are notifications sent to the right people?
• Is the approval history saved clearly?
• Can a user approve their own request when they should not?
• What happens if an approver is absent or inactive?

If your business depends on approval gates, do not leave this testing to one person. Ask representatives from each department to test their part of the process. A workflow that looks correct to management may feel confusing to the employees using it every day.

3. Check Arabic, English, Forms, and Mobile Usability

For companies in Saudi Arabia and the Gulf, language and usability are not small details. Arabic and English content must both be clear, consistent, and usable across devices.

Start with Arabic interface checks. Confirm that text alignment, right-to-left layout, labels, buttons, validation messages, and menus work properly. Arabic fields should display correctly in forms, tables, exported files, PDFs, emails, and notifications. Names and addresses should not appear broken or reversed.

Then check English content. Many businesses operate with bilingual teams, and mixed-language systems are common. Make sure the same action has the same meaning in both languages. For example, if Arabic says “Submit for approval,” the English button should not simply say “Save” if the action starts an approval process.

Forms deserve detailed testing because they are where users make the most mistakes. Review:

• Required and optional fields
• Clear field labels
• Validation messages
• File upload limits and accepted formats
• Dropdown options
• Date formats
• Phone number formats
• VAT or invoice fields
• Address fields for local cities and regions
• Error messages in Arabic and English

Also test on the devices your team actually uses. If branch employees, sales teams, or managers will use the system from phones or tablets, UAT must include mobile testing. Check whether buttons are easy to tap, forms are not too long, tables are readable, and approvals can be completed without switching to a desktop.

A system can be technically correct but still difficult to use. During UAT, ask users to note confusing steps, unclear labels, or repeated manual work. These comments often lead to small improvements that make the system much easier to adopt.

4. Verify Integrations, Dashboards, Reports, and Notifications

Custom business systems often connect to other tools: payment gateways, accounting software, ERP systems, SMS providers, email services, e-commerce platforms, government-related services, or internal databases. These integrations must be tested before launch with realistic scenarios.

For each integration, confirm:

• What data is sent
• What data is received
• When the sync happens
• What happens if the external service is unavailable
• Whether duplicate records are prevented
• Whether failed transactions are logged clearly
• Who receives alerts when something fails

Do not test only the successful path. For example, if a payment fails, does the order remain unpaid? If an SMS is not delivered, can the team resend it? If an accounting sync fails, does finance know which transaction needs review?

Dashboards and reports need business validation, not only technical validation. A chart may load correctly but still show the wrong definition of revenue, open requests, overdue tasks, or completed orders. Ask the department owner to confirm the logic behind each key metric.

For reports and dashboards, test:

• Filters by date, branch, department, status, and user
• Export to Excel or PDF if required
• Arabic text in exports
• User permissions for sensitive reports
• Matching totals between dashboards and detailed records
• Performance when the report has many records

Notifications are another common source of launch issues. Test email, SMS, WhatsApp if used, and in-system alerts. Confirm the message content, language, timing, recipient, and link destination. A notification that goes to the wrong role can delay work or expose sensitive information.

5. Test Edge Cases, Fixes, and Final Sign-Off

Good UAT includes normal cases and edge cases. Edge cases are situations that may not happen every day but can create serious confusion when they occur.

Examples include:

• A user starts a request but does not complete it
• A required attachment is missing
• A file is too large
• A manager rejects a request after several approval steps
• A customer enters a wrong mobile number
• Two users edit the same record
• A branch is closed or inactive
• A product, service, or employee is deactivated
• A user loses internet connection while submitting a form
• A duplicate customer or invoice is created

Also test security-related behavior in simple business terms. Can users access a page by copying a link? Does the system log out after inactivity if required? Are deleted records recoverable or at least tracked? Are sensitive fields hidden from users who do not need them?

When users find issues, record them in one shared list. Each issue should include the scenario, steps to reproduce it, expected result, actual result, screenshot if possible, priority, owner, and status. Avoid sending feedback only through scattered messages, because important items will be missed.

After fixes are completed, retest the exact scenario. Do not assume a fix works because it was marked done. Also check that the fix did not affect related workflows.

Before launch, create a formal sign-off step. This does not need to be complicated. It can be a simple approval from each business owner confirming that critical workflows have been tested and accepted. For example:

• Sales accepts customer and lead workflows
• Finance accepts invoices, payments, and exports
• Operations accepts order or request handling
• HR accepts employee-related workflows
• Management accepts dashboards and permissions

Final sign-off gives everyone clarity. It confirms that the system is ready for go-live, or that remaining issues are known and accepted.

Takeaways

• UAT should be led by business workflows, not only technical test cases.
• Test every user role, permission level, and approval path before launch.
• Arabic, English, mobile usability, forms, and exports need careful review.
• Integrations, notifications, dashboards, and reports must be validated with realistic data.
• Track issues in one shared list, retest fixes, and get clear business sign-off before go-live.

A careful UAT process protects your team from avoidable launch problems and gives decision-makers confidence that the system supports real operations. If you are preparing to launch a custom system and want a second opinion on your testing checklist, Pioneers.dev offers a free tech consultation via WhatsApp.