UAT Design for ERP Programmes
ERP UAT is not function testing with business users clicking around. It’s a structured simulation of real business operations, role by role, process by process, at the volume and complexity of actual go-live conditions.
1 The Hook
A Ministry agency goes live on Oracle Fusion Financials after 6 months of SIT. UAT ran for 4 weeks with 12 business users. Sign-off is achieved. Week 2 of production: the Accounts Payable team cannot process overseas payments in USD. The multi-currency module was configured but never included in any UAT scenario. The test scripts covered NZD transactions only.
Overseas suppliers go unpaid for 3 weeks while the configuration is diagnosed and fixed. The UAT design was functional-component-based — it tested individual screens and modules. It was not business-process-based. Nobody asked: “What does the AP team actually do on a Tuesday afternoon?”
The answer would have been: “We pay 30 NZD invoices and 8 USD invoices from our US software vendors.” That’s the scenario that should have been in UAT. It wasn’t. And sign-off was meaningless without it.
2 The Rule
Design ERP UAT scenarios from real business processes, not from system modules. A business user does not test “the Accounts Payable module” — they test “paying the electricity bill from receipt to payment run.”
3 The Analogy
Designing UAT from modules is like testing a restaurant by testing the kitchen, the dining room, and the till separately.
The real test is whether a customer can walk in, order, eat, pay, and leave happy — end to end. The kitchen, dining room, and till are just stops along the way. Test the journey, not the rooms. A restaurant where the kitchen passes inspection and the till passes inspection but the waiter can’t take the order will fail every real customer it serves.
4 Watch Me Do It
A full UAT script for a Procure-to-Pay business process in Oracle Fusion — a $5,000 NZD office equipment purchase from a local supplier.
Roles required: Requestor (office admin) · Approver (manager, authority to $10,000) · AP Clerk · Finance Director (month-end reconciliation)
Roles: Requestor, Approver, AP Clerk
Precondition: Supplier “Office Max NZ” exists and is active. Budget for cost centre CC001 exceeds $5,000.
Step 1 (Requestor): Create Purchase Requisition
Navigate: Procurement > Purchase Requisitions > Create
Enter: Item “Office Chairs x10”, Qty 10, Unit Price $500, Cost Centre CC001
Submit for approval
Expected: Status = “Pending Approval”. Email notification sent to Approver.
Step 2 (Approver): Review and Approve
Navigate: Approvals Worklist
Verify: correct items, cost centre, amount within delegated authority
Action: Approve
Expected: PR status = “Approved”. Purchase Order auto-generated.
Step 3 (AP Clerk): Goods Receipt + Invoice Match
Record goods received: 10 chairs received in full
Create supplier invoice for $5,000 + GST
Verify 3-way match passes (PO / Receipt / Invoice)
Expected: Invoice status = “Ready for Payment”
Step 4 (AP Clerk): Payment Run
Include in next weekly payment run (Friday EFT batch)
Verify payment method = EFT, bank account correct for Office Max NZ
Run payment
Expected: GL journal created. Accounts Payable balance reduced by $5,000 + GST. EFT file generated.
5 When to Use It
Every ERP UAT, without exception. The key design principles to apply:
- End-to-end business process scenarios covering all major financial and operational flows, not just individual screens
- Role-based testing — each user tests their own actual workflow, using the role and permissions they will have in production
- Volume simulation — run realistic transaction volumes, not just one or two examples. If the AP team processes 200 invoices per week, run 200 invoices through the UAT environment
- Currency and exception coverage — explicitly identify every currency, every supplier type, every approval path, and make sure each has at least one scenario
6 Common Mistakes
🚫 “Power users from IT can run UAT instead of actual business users.”
Actually: power users know the system but not the business edge cases. The AP clerk who processes 200 invoices a month will find issues the IT analyst who configured the system will never encounter — because they know what “wrong” looks like in the context of their real work. UAT must be run by the people who will actually use the system in production.
🚫 “If SIT passed, UAT is a formality.”
Actually: SIT tests that the system functions as configured. UAT tests that the system works for the actual business at actual volume. These are different things. SIT passing means the system can post a journal. UAT passing means the finance team can close the month. One does not predict the other.
🚫 “UAT sign-off means the system is ready for go-live.”
Actually: sign-off means the tested scenarios passed. Outstanding risks, approved workarounds, and untested edge cases must be documented in the go-live risk register with a business owner and a resolution timeline. Sign-off without a risk register is a blank cheque.
7 Now You Try
Paste or edit the prompt below, then click Run to get a real AI response.
8 Self-Check
Click each question to reveal the answer.
Q1: What is the difference between SIT and UAT in an ERP context?
SIT (System Integration Testing) verifies that the configured ERP functions correctly — that workflows route to the right approvers, that integrations pass data correctly, that batch jobs produce the expected output. It is typically run by the project team and SI. UAT (User Acceptance Testing) verifies that the configured ERP works for the actual business at actual volume — that the Finance team can close a period, the AP team can process a payment run, and the sales team can raise a quote and convert it to an order. It is run by business users in conditions that simulate production. SIT passing is a precondition for UAT, not a substitute for it.
Q2: What is parallel run testing and when is it appropriate?
Parallel run testing means operating both the old and new systems simultaneously for a defined period, processing real transactions in both, and comparing outputs. It is appropriate when the cost of a go-live failure is very high — typically for finance systems processing payroll, accounts payable, or general ledger where an error means real money going to the wrong place. It is resource-intensive (users must do twice the work) and requires a defined reconciliation process to compare outputs. It is the most reliable final validation before full cutover because it uses real data at real volume.
Q3: What should a UAT sign-off document contain?
A UAT sign-off document should contain: the scenarios that were tested and their pass/fail outcomes; a list of defects found, their severity, and their resolution status (fixed, deferred, accepted); any approved workarounds in use at go-live; outstanding risks not covered by the tested scenarios, with a business owner for each; and the names and roles of the business users who participated. It is signed by the business owner, not the test team. The test team can report the results; only the business can accept the risk of going live.
9 ISTQB Mapping
CTAL-TM v3.0 — Section 4.3: Test execution, including acceptance testing strategy — the role of the test manager in planning UAT scope, facilitating business user participation, and managing sign-off.
CTFL v4.0 — Section 4.4: Acceptance testing — purpose, techniques, and the distinction between user acceptance testing and operational acceptance testing in an ERP programme context.