Your partner has scheduled four weeks of user acceptance testing. Three of those weeks will be spent waiting for an environment, chasing people who have day jobs, and arguing about whether something is a defect or a change request. Then somebody will sign a page and everyone will pretend that meant something.
UAT is the last point at which the business can say no cheaply. Run it as a ritual and you give that away. Run it properly and it is the single most valuable four weeks in the project.
Table of contents
What UAT is for, and what it is not
The confusion that wrecks most ERP test phases is that four different activities get called “testing” and then get run as one.
| Test level | Question it answers | Who runs it | When it is done |
|---|---|---|---|
| Unit and component testing | Does this piece of configuration or code behave as specified | Developers and functional consultants | Before anything reaches a shared environment |
| System testing | Does the configured solution meet the requirements as a whole | The implementation team | Before integration testing |
| System integration testing | Do the interfaces move the right data between systems, in both directions, including failures | Technical and integration leads | Before UAT starts |
| User acceptance testing | Can the business run its real processes and will it accept the system | The business, in their own roles | Last |
The ISTQB glossary definition is useful because it is narrow: user acceptance testing is acceptance testing carried out by future users in a simulated operational environment, focused on user requirements and needs, to determine whether to accept the system.
Two words in that do a lot of work. Future users, not consultants demonstrating to an audience. Accept, not verify, because acceptance is a business judgement rather than a technical result.
The practical consequence is that UAT is not the place to discover that an interface drops records or that a report does not exist. Those are integration and system testing failures, and if they surface during UAT the phase before it was not completed.
ISTQB’s acceptance testing syllabus also places UAT alongside contractual and regulatory acceptance testing and alpha and beta testing, a useful reminder that on a regulated ERP project you may owe more than one kind of acceptance evidence.
Pick scenarios by business process, not by screen
The default UAT plan is a list of screens with someone assigned to each. It produces excellent coverage of fields and no coverage of the business.
Test by process instead. A process scenario starts where work actually starts and ends where money or goods actually move. “Enter a sales order” is a screen. “Customer on credit hold places an order that exceeds their limit, the credit controller reviews and releases it, the warehouse picks and despatches, the invoice posts and the customer pays short” is a process, and it exercises eleven screens, three approval routes, two integrations and one exception path that nobody had thought about.
Build your scenario list from the process inventory, then rank it:
- Tier 1, must pass: the processes that generate revenue, pay people, pay suppliers and close the books. Order to cash, procure to pay, record to report, hire to retire. Every variant that carries meaningful volume.
- Tier 2, should pass: significant but non blocking processes. Returns, credit notes, intercompany recharges, fixed asset disposals, stock adjustments.
- Tier 3, nice to have: low volume and low value processes where a documented workaround for the first month is acceptable.
Then deliberately add exception scenarios, because they are where ERP projects break. The part shipped short. The invoice that does not match the purchase order. The customer who pays two invoices with one payment and deducts a credit note.
Roughly a third of your Tier 1 scripts should be exceptions, and if that sounds high, count how many of last month’s real transactions went through without a single deviation.
Scenarios should also run against migrated data rather than clean demonstration data. Testing order entry against a made up customer proves the configuration. Testing it against the customer record that came out of the legacy system proves the data migration, which is the thing more likely to be wrong.
Writing a script a finance user can actually execute
A test script written by a consultant for a consultant reads like “Create SO, apply discount, confirm posting”. A finance user cannot run that, will improvise, and will produce a result nobody can reproduce.
A usable script has numbered steps, exact input values, an expected result per step, and space for what actually happened. The test data is specified, not left to the tester. And crucially the expected result is stated in business terms, so that the tester can tell the difference between a defect and their own mistake.
Sample script: SC-OTC-07, credit held order released and despatched short
| Step | Action | Test data | Expected result | Actual | Pass/Fail |
|---|---|---|---|---|---|
| 1 | Open the customer record | Customer C-10442 (migrated, on credit hold) | Credit hold indicator is visible, credit limit shows GBP 25,000 | ||
| 2 | Create a sales order for the customer | Item SKU-8831, quantity 40, unit price GBP 900 | Order saves with a total of GBP 36,000 and status Credit Hold | ||
| 3 | Attempt to confirm the order | None | Confirmation is blocked and the message names the credit limit breach | ||
| 4 | Log in as credit controller and open the held orders queue | User: credit.controller | The order appears in the queue with the customer’s exposure shown | ||
| 5 | Release the order with a reason code | Reason: Approved by FD, ref FD-2291 | Order status changes to Released, reason and approver are recorded in the audit log | ||
| 6 | Log in as warehouse user and pick the order | Available stock: 30 units only | System allows a part pick of 30 and leaves 10 on back order | ||
| 7 | Despatch the picked quantity | None | Despatch note shows 30 units, order remains open for 10 | ||
| 8 | Post the invoice | None | Invoice value is GBP 27,000, matching the despatched quantity, not the ordered quantity | ||
| 9 | Check the customer ledger | None | AR balance increases by GBP 27,000 and the customer is back within the credit limit | ||
| 10 | Check the back order report | None | Remaining 10 units appear with the original order reference and requested date |
Note what makes this executable. Real migrated data. Named users for each role, so role security is tested as a side effect. Numbers the tester can check without a calculator. Expected results in business terms, including the one at step 8 that quietly tests whether invoicing follows despatch rather than order.
On documentation format, the standard worth knowing is ISO/IEC/IEEE 29119-3:2021, which specifies test documentation templates and is the current successor to IEEE 829, superseded since 2013. You do not need to buy it to run a good ERP UAT, but if your contract or your auditor references IEEE 829, that reference is out of date.
Defect triage and severity that mean something
Severity arguments consume more UAT hours than testing does, almost always because severity was never defined. Define it once, in writing, before the first script runs, and separate it from priority.
Severity is the impact on the business if this ships as is. Priority is the order in which it gets fixed. A cosmetic defect on the invoice a customer sees can be low severity and high priority.
A severe defect in a process that runs once a year can be high severity and low priority.
| Severity | Definition | Example | Response | Blocks go-live |
|---|---|---|---|---|
| S1 Critical | A Tier 1 process cannot be completed at all, or the system produces a financially incorrect result with no workaround | Invoices post at the ordered quantity rather than the despatched quantity | Fix immediately, retest the full scenario, notify sponsor same day | Yes, always |
| S2 Major | A Tier 1 process can be completed but only through a workaround that is not sustainable at volume | Credit release works but requires an administrator to edit the record directly | Fix before go-live, or accept with a documented workaround approved by the process owner | Yes, unless formally accepted |
| S3 Moderate | A Tier 2 process is impaired, or a Tier 1 process has a defect with a sustainable workaround | Back order report omits the requested date | Schedule for the first post go-live release | No |
| S4 Minor | Cosmetic, wording, layout, or a low volume inconvenience | Column header truncated on an internal enquiry screen | Backlog | No |
| S5 Enhancement | Works as designed, the business would prefer something different | Requests an extra filter on the held orders queue | Change request, not a defect | No |
Two rules keep the register honest. The tester proposes the severity and the triage group decides it, because testers under pressure inflate and consultants under pressure deflate. And S5 is a real category that must be used, because the most common way a UAT register becomes meaningless is by absorbing scope requests as defects until the open count is unreadable.
Run triage daily during UAT, not weekly. A defect raised on Monday and triaged on Friday costs four days of a four week phase. Twenty minutes each morning with the test lead, a functional consultant and one business representative is enough.
Entry and exit criteria
UAT starts and stops on criteria, not on dates. Write both down before the phase begins and get them signed by the same person who will later sign the acceptance.
Entry criteria. UAT does not start until all of these are true:
- System integration testing is complete and all S1 and S2 defects from it are closed
- The UAT environment is a separate, stable environment refreshed with migrated data from the most recent full load
- Every Tier 1 and Tier 2 scenario has a written script with expected results
- Testers are named, released from day job commitments for defined hours, and trained on the system
- The defect register, severity definitions and triage schedule exist and have been agreed
- Security roles are configured, so testers log in as themselves in their real role
The environment point is the one most often fudged. Testing in a shared development environment while consultants change configuration underneath you produces results nobody can reproduce.
Exit criteria. UAT is complete when:
- 100 per cent of Tier 1 scripts have been executed and passed
- At least 95 per cent of Tier 2 scripts have been executed, with any failures triaged at S3 or below
- Zero open S1 defects
- Zero open S2 defects, or each one formally accepted in writing by the process owner with a documented workaround
- Every fixed defect has been retested by the original tester, not by the person who fixed it
- A regression pass has been run over the Tier 1 scripts after the final defect fix deployment
- Test evidence is complete: every executed script has a recorded actual result and a tester name
That last regression pass is regularly dropped for time, and it is the one that catches the fix that broke something else. Protect it in the plan.
Is your UAT plan a test phase or a demonstration?
Alphavima builds UAT scenario packs from your real business processes, writes scripts your finance and operations users can execute unaided, and runs the triage that keeps the register honest. Book a UAT planning session before the environment is booked.
Get Your Quote +1 (289)-805-2631What sign-off should mean
A signature that means something is attached to a specific statement: that a named person, accountable for a named process, has personally seen the evidence that the process works with migrated data in the target environment, and accepts the listed open defects with the listed workarounds.
That is a paragraph, not a tick.
Sign off by process owner, not by project manager. The project manager’s signature says the phase ran. The process owner’s signature says the business will operate this on Monday, and only the second is worth anything when something goes wrong in week three.
Make the accepted defects visible in the sign-off document itself, listed line by line. People sign differently when the compromise is on the page in front of them rather than in an appendix.
That list feeds directly into the go-live readiness assessment, where the workarounds become criteria to score, and into the cutover plan, where they become briefing material for the hypercare team.
Keep the executed scripts. They are the fastest regression pack you will have for the first upgrade, and the evidence you will want if anyone later asks what exactly was accepted.
The failure modes to watch for
Four patterns account for most unsuccessful ERP UAT phases, and all four are visible early.
Testing by demonstration. A consultant drives while users watch. Everything passes, and nothing has been tested, because the person who knows the system’s quirks is avoiding them by reflex. If the consultant’s hands are on the keyboard, it is training.
Clean data. Scenarios run against demonstration records rather than migrated ones. The configuration is proven, the migration is not, and the migration is the higher risk.
Absent testers. People nominated for UAT still carry a full workload, attendance decays through the phase, and the last week is done by two enthusiasts. Release testers formally, in writing, with named backfill.
Severity drift. Without written definitions, S1 becomes whatever the loudest person calls it and the register stops being a decision tool.
Get those four right and the rest of UAT is administration. Get them wrong and the sign-off page is the only artefact the phase produces.
Related reading
Frequently asked questions
What is the difference between UAT and system integration testing?
System integration testing proves that data moves correctly between systems, in both directions, including failure handling, and it is run by the technical team. User acceptance testing proves that the business can run its real processes and is willing to accept the system, and it is run by the future users themselves. Integration defects surfacing during UAT mean the earlier phase was not finished.
Who should write ERP UAT test scripts?
A test lead writes the structure and the expected results with input from the process owner, and the process owner validates that the scenario reflects how the work is really done. Scripts written entirely by consultants test the configuration as designed rather than the process as practised.
How long should ERP user acceptance testing take?
Long enough to execute every Tier 1 script, fix the defects, retest them and run a regression pass. Counting backwards from that, rather than allocating a fixed number of weeks, is the only reliable way to size it. Two shorter cycles with a fix window between them usually beat one long continuous phase.
What is the difference between defect severity and priority?
Severity measures the business impact if the defect ships as is. Priority measures the order in which it gets fixed. They routinely differ: a cosmetic error on a customer facing invoice can be low severity and high priority, and a serious flaw in an annual process can be high severity and low priority.
Can we go live with open defects?
With S3 and below, routinely. With S2, only where the process owner has accepted a documented workaround in writing. With S1, no. The distinction has to be enforced by the definitions agreed before testing started, not renegotiated in the week before go-live.
What should ERP UAT sign-off actually say?
That a named process owner has seen evidence that their process works end to end with migrated data in the target environment, and accepts the specifically listed open defects with the specifically listed workarounds. The accepted defects belong in the body of the document, not in an appendix.
Is IEEE 829 still the standard for test documentation?
No. IEEE 829 was superseded by ISO/IEC/IEEE 29119-3, now in its 2021 second edition, which specifies test documentation templates applicable to any organisation, project or testing activity. If a contract or an audit checklist still names IEEE 829, it is out of date.