Integration testing in ERP implementation

The problem addressed by the integration test in ERP implementation

The integration test differs fundamentally from unit and system tests: it does not test the isolated functionality of individual modules, but their interoperability under real data flow conditions.

In SMEs, we often see the same misconception: you first test individual modules (unit testing is solved), then validate the system as a whole (system testing appears successful), but jump straight into user acceptance testing — skipping the critical phase of interface testing.

This is the point at which invisible errors occur. A warehouse module can work in isolation without errors. A finance module can process all invoice logic correctly. But as soon as the warehouse module transmits a movement to financial accounting, an incorrect interface mapping, an incorrect data-type conversion, or a race condition under load can lead to inconsistencies — and these only arise under integration conditions.

According to the ISTQB Glossary, integration testing is "testing performed to expose defects in the interfaces and in the interactions between integrated components or systems". This is precisely what is underestimated in SMEs.

An overview of the methodology

In practice, integration testing methodology follows five successive phases, each of which delivers specific results.

From over 50 mid-market projects in the DACH region we recommend the following procedure:

Phase 1: Interface prioritisation and test case inventory The first step is not to program, but to map. Which interfaces are business-critical? A master data interface has a higher risk than an audit-log interface. You identify the top 10 critical data flows (e.g. order → warehouse → finance) and define a test case with a specific input/output scenario for each.

Phase 2: Test data masking under GDPR Integration tests require realistic data volumes. This often means production clones with real customer numbers, bank accounts, and address data. Data protection is not optional here. You mask personal data according to the GDPR standard (customer names, social security numbers, telephone numbers) — but you must not change the data structure, length, or consistency, otherwise your integration test will test the wrong reality.

Phase 3: Test case design with regression strategy For each interface, you define: positive scenarios (happy path — standard data flow), negative scenarios (error case — what happens if a field is empty? if an external system does not respond?), and limit-value scenarios (maximum field lengths, decimal places). Each test case is documented so that the test remains reproducible for the next vendor patch (SAP update, cloud release).

Phase 4: Hybrid automation — manual + tool-based tests Mid-market companies rarely have the capacity for full test automation. Our recommendation: key user teams carry out business-process tests manually (this is the expertise they have — process knowledge). Automate regression tests and load tests with tools such as JMeter or WMS-specific test tools.

Phase 5: Documentation and sign-off Every test is documented — what input, what expected output, what actually happened. Process owner and IT management sign the integration-test log. This is not formalism — this is risk management for the go-live.

Practical example: key user-based test organisation in SMEs

Test organisation works differently in SMEs than in corporations — key users have to validate business logic, not QA specialists.

A south German mechanical engineering company with 280 employees introduced a new ERP system two years ago. The implementation team was small: 2 consultants, 1 IT administrator, 5 key users from sales, production, and logistics. Classic textbook testing was not realistic.

Instead, they organised it like this:

Week 1–2: Interface workshop. The key users from each department identified their critical data flows: quotation → order → production planning → stock booking → invoicing. A total of 12 interface scenarios.

Week 3–4: Test case construction. The consultants defined detailed test cases for each scenario (what is entered? what is the expected output?). The key users validated these against their business experience: is this realistic? Have we missed any edge cases?

Week 5–6: Execution. Each key user group executed their test cases. Two IT tools automated the regression (the automatic re-check of whether a previous test still works after the latest system update).

Result: 48 errors identified; 36 were genuine integration defects (e.g. decimal-place rounding in price calculation, missing field mapping in stock posting). Go-live could take place without these errors. No post-cutover emergency.

This works because the key users understand what is "wrong" — not because they are testers, but because they know the business.

Common mistakes in integration testing in SMEs

Three systematic mistakes delay go-lives by months and lead to production crises.

Mistake 1: the formal test phase is skipped. The pressure is on — go-live is scheduled. Integration testing sounds time-consuming. Some implementation teams say: "We'll do it in UAT" — but UAT (User Acceptance Testing) tests whether the requirement has been implemented, not whether the interfaces are data-flow consistent. These are different questions. You need both phases. If the formal integration-test phase is skipped, interface errors only become visible after go-live — at which point the cost is many times higher.

Mistake 2: manual scaling of the test volume fails. A good integration-test scenario with 10 test cases looks manageable. Then comes reality: the system has 47 interfaces, not 10. A team of 5 key users cannot work through 470 test cases manually — not in 4 weeks. Without hybrid automation (automation for regression, manual tests for edge cases), this approach collapses.

Mistake 3: vendor-patch regressions are ignored. The integration test takes place and runs successfully. Then, two weeks before go-live, the vendor releases a security patch. A critical error in the finance function is fixed. That sounds good — but the patch could affect an interface. You don't run the integration test again? That is a risk. We recommend: the regression-test suite is alive — it runs again with every patch.

What most integration testing textbooks don't explain

Academic test methodology and SME reality drift apart on three critical points.

1. ISTQB definition vs. SME practice: what is integration testing really?

ISTQB defines integration testing as the testing of interfaces between components. This is technically correct. But in the SME context, the business impact is missing: integration testing is not just "does system A send the data package to system B with the correct syntax?" — it is also "if we enter a real sales order, is it processed consistently through all modules to the business result (invoicing)?"

This is why key user-based integration testing is not based on detailed technical knowledge, but on an understanding of the business process. A key user from sales notices immediately if a price is passed on incorrectly. A finance specialist notices if the cost centre is not transferred. This is not QA expertise — this is specialist knowledge. And that is where SME teams have an advantage.

2. Resource reality: QA teams do not exist in SMEs

ISTQB and the ISO/IEC/IEEE 29119 series (the current international standard for software test documentation, which has superseded the older IEEE 829 since 2013) assume: there is a dedicated QA team. In SMEs, you have a team of business users who test on the side. This does not mean that you test less carefully — it means that you need pragmatic automation.

Our practice: don't roll out full test automation (too expensive, too long). Instead, automate the repeatable, high-frequency tests (master-data upload, interface regression after patches). The business-process tests are carried out by the key user team because they can best validate whether the result is "correct".

And with multi-tenant SaaS systems (e.g. SAP S/4HANA Cloud): you often can't look into the system code; you only test from the outside. This requires black-box-testing discipline, not white-box automation.

3. Continuous patches + data isolation: SaaS-ERP reality

From our advisory practice: SaaS-ERP systems receive updates monthly, sometimes weekly. Every update could affect an interface. On-premise systems had the luxury of receiving patches once every six months, planned and tested. With SaaS, that's a thing of the past.

At the same time, Germany's NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) — in force since December 2025, with BSI registration required by March 2026 — requires operators of essential and important entities to maintain documented and continuously verified integration tests. This is not theoretical — it has been a binding compliance requirement since early 2026.

SMEs with SaaS ERP therefore need live test scenarios, not one-off test campaigns. And because data is shared between tenants in multi-tenant systems, data isolation and masking is not a data-protection formality — it is a test-integrity requirement.

Our take: Integration testing is not optional or "nice-to-have" in modern ERP implementations — it is the difference between go-live success and post-cutover emergency. The methodology must fit the resource reality of SMEs, not standard corporate textbooks.

Application in DACH SME verticals

Industry-specific requirements change which interfaces are critical.

Mechanical engineering: Critical interface flows are calculations (BOM explosion), scheduling (capacity utilisation), and material provision (just-in-sequence for assembly). Integration tests must validate decimal accuracy and time consistency. Special feature: customer-specific adaptations arise in every project — the test-case library must be scalable for this.

Food industry: Batch tracking and expiry-date management are key. Integration tests must check: batch numbers flow consistently through all modules; expiry dates automatically trigger stock movements. GDPR is less relevant (anonymous food), but the EU Food Information Regulation (FIC, Reg. 1169/2011) and HACCP audit duties require allergen declarations and end-to-end audit trails.

Wholesale: The main interface is stock management ↔ customer system. In B2B e-commerce, every order update must synchronise stock availability in real time. Race conditions are common here (two customers order at the same time, but only one unit is available). Integration tests must include concurrency scenarios.

Next steps

If you are planning an ERP implementation, it makes sense to outline the integration-test methodology before the requirements phase, not three weeks before go-live. This sounds early, but it is crucial: the earlier you clarify which interfaces are critical and how you will test them, the earlier you can select automation tools and prepare test data.

Our recommendation: invite process owners, IT management, and the operational-excellence team to an integration-test workshop. Map the critical data flows in two days. The output is an integration-test plan that becomes part of the project budget and timeline.

Matthias Müller and the Dreher team will be happy to support you with this workshop and the methodology rollout. Across more than 50 mid-market projects in the DACH region we see consistently: in every project where integration testing was done properly, the go-live was smooth. That is not a forecast — it is documented experience.

Matthias Müller
Senior Consultant Process Optimisation, ERP & Digitalisation

Matthias supports mid-market companies through complex ERP implementations and specialises in the methodical integration of process design and system selection.

Schedule Meeting

Frequently Asked Questions

Where does integration testing end and user acceptance testing (UAT) begin?

Integration testing validates technical data-flow consistency between modules and systems. UAT validates whether the business requirement is met. Example: integration testing confirms an order correctly transfers from sales to warehouse (technical interface). UAT confirms that a salesperson can work with it and that the business outcome is correct. Both are necessary, not competing

Must we re-run integration tests after every vendor update?

Yes — but with graduated effort. After critical security patches, you at minimum re-run the regression-test suite (automated, fast). After larger feature updates you assess which modules are affected and re-test only those interfaces. After minor updates (bugfixes, UI improvements) a light smoke-test check may suffice — that depends on your implementation team's risk assessment.

Can AI-driven test automation automate integration testing?

AI tools excel in data analysis — pattern recognition across multiple similar projects remains a consultant capability. For integration tests: AI can help identify test patterns (e.g., "all decimal-field interfaces should be tested for rounding edge cases"). But defining what is "correct" cannot be AI-dependent — that requires the DACH mid-market reality interpretation that a key user or consultant brings. Standardised AI answers are valuable for definitional questions. ERP-specific interpretation for your mid-market business does not fall into that category.

Integration testing in ERP implementation - methodology, practice and success factors