ERP Testing & UAT

Why ERP testing often fails to catch real problems

Most ERP projects do some testing. The issue is usually what kind of testing, by whom and how late. The patterns that let problems through are consistent:

• Testing by the people who built it. Configurers naturally test what they configured, in the way they expect it to be used.
• Module-by-module testing only. Each module passes on its own, but the handoffs between sales, warehouse and finance were never tested together.
• Clean demo data. Real data has odd units, long descriptions, old customers on special terms and items with missing costs.
• Happy-path scripts. Partial deliveries, returns, credit notes, approvals that are rejected and back-dated corrections are left out.
• Compressed timelines. Testing is the phase squeezed when configuration runs late, so it becomes a formality.
• No clear exit criteria. Without them, go-live happens because the date arrived.

Good ERP testing reverses each of these. It is planned early, built on business processes, run with realistic data and judged against criteria agreed in advance. It also links back to requirements, so you can show that every must-have requirement was actually tested. If your requirements are not documented well enough to test against, start with ERP requirements gathering.

Building the ERP test strategy

A test strategy does not need to be long, but it must answer a few practical questions before anyone starts clicking. I write it with your project team and the implementation partner, and it typically covers:

The strategy also sets out environments, test data, roles, the defect process, severity definitions and entry and exit criteria for each stage. Agreeing these early avoids disputes later about what was supposed to be tested and by whom. It fits into the wider plan described on my ERP implementation page.

End-to-end scenario scripts that reflect real work

The heart of ERP testing is a set of end-to-end scenarios. Instead of testing "create a sales order" in isolation, a scenario follows a complete business flow, for example:

1. A customer with special credit terms requests a quote with a discount that needs approval.
2. The quote becomes a sales order; stock is reserved in one warehouse and partly backordered.
3. A partial shipment is picked and delivered; the invoice reflects only the shipped quantity.
4. The customer returns one item; a credit note is raised and stock is restored.
5. Payment arrives through the bank feed, net of charges, and is matched to the remaining balance.
6. Sales, margin and receivables reports show the correct figures.

Each script lists the steps, the role performing each step, the test data, the expected result and space to record the actual result. Scenarios are traced back to requirement IDs, so coverage is visible.

I build scenarios for each major process area, such as order-to-cash, procure-to-pay, inventory, production, projects and record-to-report, and deliberately include exceptions, rejections and period-end tasks. Process maps from ERP process mapping are often the best source for these scripts, because they already show the handoffs where things tend to break.

Running UAT with business users and triaging defects

User acceptance testing is where the business confirms, in its own words, that the system supports its work. For that to be meaningful, the testers must be the people who will use the system, not only the project team. I make UAT workable for busy staff:

• Short briefings so testers understand the purpose and how to record results.
• Scripts written in business language, assigned by role.
• Scheduled sessions with protected time, rather than "test when you can".
• Support on hand to answer questions and capture issues in the moment.

Every issue goes into a shared defect log with a description, steps to reproduce, screenshots, severity and the related scenario. In regular triage sessions with the implementation partner, I classify each issue:

• Defect: the system does not behave as designed, and the partner fixes it.
• Design gap: it behaves as designed, but the design missed a requirement, so it is assessed through change control.
• Training need: the system works, but the user needs guidance.
• New request: a good idea for later, added to the backlog.

This separation keeps the partner focused on real defects, protects scope and gives you an honest picture of quality. Training needs found in UAT also feed directly into ERP training.

UAT sign-off criteria and the go-live decision

UAT should end with a decision, not just a date. I agree sign-off criteria with your sponsor before testing starts, so nobody is negotiating standards under deadline pressure. Typical criteria include:

• All planned end-to-end scenarios executed, with results recorded.
• No open critical defects, and high-severity defects either fixed or covered by an agreed workaround.
• Migrated data reconciled and accepted by each data owner.
• Integrations tested end to end, with monitoring in place.
• Key reports and period-end processes validated by finance.
• Process owners for each area have formally signed off.

At the end of UAT I prepare a test summary report: what was tested, what passed, what remains open, the risk of each open item and the recommended action. That report becomes a key input to the go-live checklist, alongside cutover readiness and user training. From there, ERP go-live support covers the switch and the first weeks of live use.

An independent ERP UAT consultant matters here because everyone else in the room has a reason to want a yes. The partner wants to close the phase and the internal team is tired. My job is to present the evidence plainly, so leadership can make the call with its eyes open. For the full lifecycle view, see my ERP implementation guide.