Testing an ERP

ERP testing is different: the units are business processes, not functions; correctness means “the accounting entries are right”; and the cost of a defect reaching production is measured in misstated financials, not a bug ticket.

The test levels

Level	Who	Scope	Question
Unit	Developer	One object	Does this program work?
String	Consultant	A sequence of steps in one module	Does this sub-process work?
Integration (SIT)	Team	End-to-end, cross-module	Do the processes work together?
UAT	Business users	Real business scenarios	Can we run our business on this?
Performance	Technical	Volume and load	Will it work in production?
Security	Security team	Roles and authorisations	Can people do only what they should?
Regression	Team	Everything previously working	Did this change break something?
Cutover rehearsal	Everyone	The go-live procedure	Can we execute the cutover in the window?
Parallel run	Business	Old vs new, same inputs	Do we get the same numbers?

Testing the accounting — the ERP-specific discipline

The most important test in an ERP is not “did the screen work?” It’s “are the journal entries correct?”

Test case IT-042: Goods receipt for a stock purchase order

Given:
  PO 4500001, material FAB-1000, 500 EA @ 12.50, plant DHK1
  Material valuation: standard price 12.00, valuation class 3000
  Account determination: BSX → 120000, WRX → 231000, PRD → 520000

When:
  Post goods receipt, movement type 101, quantity 500

Then, assert EXACTLY these journal lines:
  120000  Inventory raw materials       Dr  6,000.00   (500 × 12.00 std)
  520000  Purchase price variance       Dr    250.00   (500 × 0.50 diff)
  231000  GR/IR clearing                Cr  6,250.00   (500 × 12.50 PO price)

And:
  Stock quantity DHK1/RAW increased by 500
  PO 4500001 line 10 open quantity reduced to 0
  Material document created with movement type 101
  Document flow links PO → material document

Assert the exact accounts and the exact amounts. “The posting succeeded” is not a test. This is what separates ERP testing from generic application testing, and it’s what catches account determination errors before the auditors do.

Build a library of these posting assertions — one per business event. They are your most valuable regression suite, because account determination configuration changes constantly and breaks silently.

Test scenarios, not test cases

Business users cannot execute “verify field VBAP-KWMENG accepts numeric input”. They can execute:

Scenario UAT-O2C-03: Export order with partial availability and split delivery

Create a sales order for customer Rahman Textiles (export, USD)
      Material FAB-1000, 1,000 EA, requested 15 April
Verify the system confirms 600 for 15 April and 400 for 28 April
      (two schedule lines — check availability was calculated correctly)
Verify the export price list applied (USD 14.20, not the domestic BDT price)
Verify the credit check passed (exposure 320,000 of a 500,000 limit)
Create the delivery for the first schedule line
Pick and post goods issue
Verify inventory reduced by 600 and COGS posted
Create the billing document
Verify the invoice shows: correct currency, 0% export VAT,
      the customer's PO reference, and Incoterms FOB Chattogram
Verify the AR open item created with the correct due date (LC 90 days)
Print the invoice — verify the layout, the tax statement, and totals in words

Written in business language, executed by the business, signed off by the business.

What to test that people forget

Area	Because
Period boundaries	Post on the last day and first day of a period
Fiscal year end	Balance carryforward, number ranges, asset year change
Reversals and cancellations	The correction path is used constantly and tested rarely
Partial everything	Partial delivery, partial invoice, partial payment, partial receipt
Zero and negative	Zero-value line, credit note, negative stock
Rounding	Amounts that don’t divide cleanly; 3-decimal and 0-decimal currencies
Foreign currency	With rate change between order and invoice
Blocked/blocked-for-X master data	Every block type
Authorisation failures	Does the user get a clear message, or a dump?
Concurrent access	Two users on the same document
Large documents	500-line order, 2,000-line invoice
Missing configuration	What happens when a tax code has no account assigned?
The unhappy path generally	Most production defects are here

“Post an invoice on the last day of the fiscal year in a foreign currency for a customer whose credit limit was just reduced, then reverse it” catches more defects than a hundred happy-path tests.

Automated testing

Type	Automate?
Posting logic and calculations	✅ Absolutely — the highest ROI
Custom program unit tests	✅ Yes
API/interface contract tests	✅ Yes
Data validation rules	✅ Yes
Regression of core processes	✅ Yes, worth the investment
Reports (data correctness)	✅ Yes
UI flows	⚠️ Brittle in ERP; automate only the highest-value paths
Print layout	❌ Visual review
UAT	❌ Human judgement is the point

Tools: the platform’s native framework (ABAP Unit, AL test codeunits, Odoo TransactionCase, Frappe tests), Tricentis Tosca (dominant in SAP), Worksoft, Selenium/Playwright for web UIs, plus your own API-level test harness.

The highest-value automated suite in any ERP is the posting assertion library, run on every configuration change and every transport. It’s also the cheapest to build, because it’s API-level, not UI-level.

Test data

The hardest practical problem in ERP testing.

Approach	Pros	Cons
Production copy	Realistic, full volume	Personal data, salaries, prices — a privacy breach waiting to happen
Masked production copy	Realistic and compliant	Masking must be thorough and consistent across tables
Synthetic	No privacy issue	Never covers the weird real cases
Curated golden dataset	Repeatable, stable	Effort to build and maintain

Masking rules: names, addresses, emails, phone numbers, tax IDs, bank accounts, salaries, and personal identifiers. Masking must be referentially consistent — customer 100 must have the same masked name in every table, or joins break and the data becomes useless for testing.

Copying unmasked production HR or customer data to a test system is a reportable data breach in most jurisdictions. This is not a theoretical risk; it’s a common audit finding.

Performance testing

What to test:
  - Interactive response time at peak concurrency
  - The month-end close batch chain, at full volume
  - The heaviest reports against full data
  - MRP / settlement / depreciation runs
  - Peak-day order entry (Black Friday, season start, month-end)
  - Interface throughput at peak
  - Concurrent batch + interactive load together

Against:
  - Production-volume data (a full masked copy)
  - Production-equivalent hardware
  - Realistic concurrency

“It was fast in DEV with 500 records” is the epitaph of many go-lives. Performance test before UAT, not after — if a report needs redesigning, you want to know while there’s still time.

Regression testing

Every configuration change and every transport can break something unrelated. Configuration is global; a change to account determination affects every module that posts.

Build a core regression pack: 30–60 scenarios covering the critical end-to-end flows and their expected postings. Run it:

Before every transport to production
After every support pack or version upgrade
Before every month-end
After any configuration change to a shared object

This is the single highest-value testing investment on an ERP project, and it pays off for the entire life of the system, not just the project.

UAT — getting it right

UAT fails when it’s treated as a formality. What makes it work:

Real users, not IT. The person who does the job daily.
Real scenarios, drawn from actual past transactions.
Real data — their own customers, their own materials.
Protected time — users released from their day job, not doing UAT “when they get a chance”.
A defect process with triage, severity, and daily review.
Exit criteria agreed in advance: e.g. zero critical, zero high, ≤5 medium with workarounds.
Sign-off by process owners, documented.

Defect severity:

Critical  Cannot go live. Wrong postings, data loss, process blocked
High      Major impact, no acceptable workaround
Medium    Impact with a workaround
Low       Cosmetic, minor inconvenience

Watch for severity inflation. Everything becomes “critical” near go-live. A triage meeting with the process owner and the project manager, held daily, keeps it honest.

The parallel run

For payroll and financial reporting, run old and new simultaneously and reconcile:

Payroll parallel run, 2–3 cycles:
  Legacy gross    18,442,110      New gross    18,442,110   ✅
  Legacy tax       2,118,340      New tax       2,118,290   ❌ diff 50
  → investigate: 3 employees with a mid-month grade change,
    retro calculation differs → fix, rerun, reconcile again

Non-negotiable for payroll. Also strongly advised for the first month-end financial close. It is exhausting for the staff running two systems, and it is the reason payroll go-lives succeed.

The go/no-go criteria

Agreed in advance, objectively assessed:

Going live with open critical defects is how projects become case studies. If the criteria aren’t met, the correct answer is to move the date. That decision is uncomfortable and almost always cheaper than the alternative.