Infor M3 User Acceptance Test Script Template
User acceptance testing is where business people confirm M3 supports the way they work. This template gives each tester a clear script with data, steps, expected results and a sign-off line.
Fill in
Infor M3 User Acceptance Test Script Template
Test header
Project: M3 CloudSuite Implementation Test ID: UAT-OTC-003 Scenario: Customer order with partial shipment and invoice Process area: Order to cash Tester: Customer service lead Date: 2026-11-09 Environment: TST tenant, data loaded from mock 2
Preconditions
Customer, item and price list exist. Stock available in main warehouse. Tester has customer order and delivery roles.
Test data
Customer: test customer 1001. Item: TEST-ITEM-01. Quantity: 100. Ship 60 now and 40 later.
Test steps
| Step | Action | Expected result | Actual result | Pass or fail |
|---|---|---|---|---|
| 1 | Enter customer order header and lines | Order saved with correct price and delivery date | ||
| 2 | Release order and allocate stock | Lines allocated, status updated | ||
| 3 | Pick and confirm first shipment | Delivery created for the partial quantity | ||
| 4 | Print documents | Packing list and delivery note print correctly | ||
| 5 | Run invoicing | Invoice posted for shipped quantity only | ||
| 6 | Review order status | Remaining quantity stays open |
Defects raised
| Defect ID | Step | Description | Severity |
|---|---|---|---|
Sign-off
Replace the sample steps with the real sequence of M3 panels and programs from your configured system. Attach screenshots as evidence after export.
Optional test planning help
Share your scenario list and get comments on coverage and exit criteria.
Optional. The tool and every export work without this. No spam.
How to use the script
Create one script per scenario, not per transaction. A scenario is a business story such as a customer order shipped in two parts and invoiced. Fill in the header, preconditions and test data, then write the steps in the order the user performs them in M3. Keep each expected result observable: a status, a document, a number. Print or export to Word, hand it to the tester, and collect the actual results and defects. Sign off only when every step passes or each failure has an agreed disposition.
- Use realistic data loaded in a recent mock conversion
- Give testers their real production roles, not admin rights
- Capture screenshots for key steps as audit evidence
- Log defects with severity so go-live decisions are clear
Choosing scenarios
Cover the end to end flows that run the business: order to cash, procure to pay, plan to produce, inventory movements, month end close and the top interfaces. Add negative cases such as a credit hold, a short receipt or a rejected inspection. Prioritize by business risk and volume. A scenario that touches money, customers or regulators gets a script. A rarely used report may be covered by a short check instead.
Pass, fail and defect handling
Define severity before testing starts. A blocker stops a process, a major has a workaround, a minor is cosmetic. Agree the exit criteria with the steering group, for example no open blockers and an agreed list of majors with fixes or workarounds. Retest after every fix and record the retest date. Keep the defect log tied to script and step so the history is traceable.
Common mistakes
Scripts that are too generic produce vague results. Testers who are not given time in their schedule skip steps. Testing in an environment without real roles hides authorization problems. Another frequent issue is signing off on a script that tested only the happy path. Include at least one exception per scenario.
Frequently Asked Questions
How many UAT scripts does an M3 project need?
It depends on scope. A mid sized manufacturing rollout often has between 40 and 120 scenarios across processes. Prioritize by risk. A smaller script set that is executed properly beats a large set that is skimmed.
Who should execute UAT?
Business users who will use M3 day to day, supported by a consultant who observes and logs defects. Consultants should not execute for them, because the goal is to prove the users can complete their work in the system.
What is the difference between SIT and UAT?
System integration testing is run by the project team to prove configuration and interfaces work technically. UAT is run by business users to confirm the system supports real processes. UAT usually follows SIT and uses more realistic data and roles.
How should I record evidence?
Export the script to PDF or Word and add screenshots of key results plus the M3 document numbers created. Store them in the project repository so auditors and future upgrade teams can see what was tested.
If you want UAT scripts drafted from your configured M3 setup and requirements, Netray can discuss an assisted approach that keeps your data on your own systems.
Related Tools
Infor M3 Go-Live Readiness Checklist
Checklist of items to confirm before an M3 go-live, grouped by data, testing, security and integration, and people and support.
Infor M3 & CloudSuiteInfor M3 Functional Specification Template
Fill-in functional specification for an M3 enhancement, interface or report, ready to export as a Word or PDF document for sign-off.
ERP Migration & SelectionInfor M3 Cutover Plan Template
Fill-in cutover plan with freeze window, task sequence, reconciliation points, go or no-go criteria and rollback triggers.
Infor M3 & CloudSuiteInfor M3 Fit-Gap Analysis Worksheet
Editable worksheet to classify each requirement as fit, configure, extend or gap, with effort and cost per line and totals by the end.
More Infor M3 & CloudSuite tools
See all- Infor M3 Program Reference (MMS001, OIS100, PMS100)
- Infor M3 MI API Transaction Call Generator
- Infor M3 Customer Order Status Tracking Worksheet
- Infor M3 Item Master Upload Worksheet
- Infor M3 MEC Mapping Design Template
- Infor M3 H5 Script Review Checklist
- Infor M3 Upgrade Test Checklist
- Infor M3 Facility and Warehouse Structure Worksheet
- Infor M3 Interface and Integration Inventory Worksheet