Integrationstest bei ERP-Einführung im Mittelstand

Das Problem, das der Integrationstest in der ERP-Einführung adressiert

Der Integrationstest unterscheidet sich grundlegend von Unit- und System-Tests: Er prüft nicht die isolierte Funktionalität einzelner Module, sondern deren Interoperabilität unter realen Datenflussbedingungen.

Im Mittelstand sehen wir häufig die gleiche Fehleinschätzung: Man testet zuerst einzelne Module (Unit-Testing ist gelöst), validiert dann das System als Ganzes (System-Testing erscheint erfolgreich), springt aber direkt ins User Acceptance Testing — und überspringt dabei die kritische Phase der Schnittstellenprüfung.

Das ist der Punkt, an dem unsichtbare Fehler entstehen. Ein Lagermodul kann isoliert fehlerfrei arbeiten. Ein Finanzmodul kann alle Rechnungslogiken korrekt verarbeiten. Aber sobald das Lagermodul eine Bewegung an die Finanzbuchhaltung übermittelt, kann ein fehlerhaftes Schnittstellen-Mapping, eine falsche Datentyp-Umwandlung oder eine Race Condition unter Last zu Inkonsistenzen führen — und diese entstehen erst unter Integrationsbedingungen.

Laut ISTQB-Glossar ist der Integrationstest „Testen mit dem Ziel, Fehlerzustände in den Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten aufzudecken". Das ist präzise das, was im Mittelstand unterschätzt wird.

Die Methodik in der Übersicht

Integrationstest-Methodik folgt in der Praxis fünf aufeinanderfolgenden Phasen, von denen jede spezifische Ergebnisse liefert.

Aus unserer Erfahrung mit über 50 Mittelstand-Projekten im DACH-Raum empfehlen wir folgendes Vorgehen:

Phase 1: Schnittstellen-Priorisierung und Test-Fall-Inventar Der erste Schritt ist nicht zu programmieren, sondern zu kartografieren. Welche Schnittstellen sind geschäftskritisch? Eine Stammdaten-Schnittstelle hat höheres Risiko als eine Audit-Log-Schnittstelle. Sie identifizieren die Top-10 kritischen Datenflüsse (z. B. Auftrag → Lager → Finanzen) und definieren für jede einen Testfall mit spezifischem Ein-/Ausgabe-Szenario.

Phase 2: Testdaten-Maskierung unter DSGVO Integrationstests benötigen realistische Datenmengen. Das bedeutet oft: Production-Clone mit echten Kundennummern, Bankkonten, Adressdaten. Hier ist Datenschutz nicht optional. Sie maskieren persönliche Daten nach DSGVO-Standard (Kundennamen, Sozialversicherungsnummern, Telefonnummern) — aber Sie dürfen dabei die Datenstruktur, Länge und Konsistenz nicht verändern, sonst testet Ihr Integrationstest die falsche Realität.

Phase 3: Testfall-Design mit Regressions-Strategie Für jede Schnittstelle definieren Sie: positiv-Szenarien (Happy Path — Standard-Datenfluss), negativ-Szenarien (Fehlerfall — Was passiert, wenn ein Feld leer ist? Wenn ein externes System nicht antwortet?), Grenzwert-Szenarien (Maximale Feldlängen, Dezimalstellen). Jeder Testfall wird dokumentiert, damit beim nächsten Vendor-Patch (SAP-Update, Cloud-Release) dieser Test reproduzierbar bleibt.

Phase 4: Hybrid-Automation — Manuelle + Tool-basierte Tests Mittelständler haben selten Capacity für vollständige Test-Automation. Unsere Empfehlung: Keyuser-Teams führen Geschäftsprozess-Tests manuell durch (Das ist die Expertise, die sie haben — Prozesskenntnis). Regression-Tests und Load-Tests automatisieren Sie mit Tools wie JMeter oder WMS-spezifischen Testwerkzeugen.

Phase 5: Dokumentation und Sign-Off Jeder Test wird dokumentiert — welche Eingabe, welche erwartete Ausgabe, was ist tatsächlich passiert. Process Owner und IT-Leitung unterzeichnen das Integrationstest-Protokoll. Das ist nicht Formalismus — das ist Risikomanagement für den Go-Live.

Praxisbeispiel: Keyuser-basierte Testorganisation im Mittelstand

Im Mittelstand funktioniert Testorganisation anders als in Konzernen — Keyuser müssen Geschäftslogik validieren, nicht QA-Fachleute.

Ein Maschinenbauer mit 280 Mitarbeitern aus Bayern führte vor zwei Jahren ein neues ERP-System ein. Das Implementierungsteam war klein: 2 Beraterinnen und Berater, 1 IT-Administrator, 5 Keyuser aus Vertrieb, Produktion und Logistik. Klassisches Schulbuch-Testing war nicht realistisch.

Stattdessen organisierten sie sich so:

Woche 1–2: Schnittstellen-Workshop. Die Keyuser aus jedem Department identifizierten ihre kritischen Datenflüsse: Angebotserstellung → Auftragserstellung → Fertigungsplanung → Lagerbuchung → Rechnungsstellung. Insgesamt 12 Schnittstellenszenarien.

Woche 3–4: Testfall-Konstruktion. Die Beraterinnen und Berater definierten zu jedem Szenario detaillierte Test-Cases (Was wird eingegeben? Was ist die erwartete Ausgabe?). Die Keyuser validierten diese gegen ihre Geschäftserfahrung: Ist das realistisch? Haben wir Edge Cases übersehen?

Woche 5–6: Ausführung. Jede Keyuser-Gruppe führte ihre Testfälle aus. Zwei IT-Tools automatisierten die Regression (das automatische Nachprüfen, ob ein früherer Test nach dem neuesten System-Update noch funktioniert).

Ergebnis: 48 Fehler identifiziert; 36 waren echte Integrationsdefekte (z. B. Dezimalstellen-Rundung bei Preisberechnung, fehlendes Feldmapping bei Lagerbuchung). Go-Live konnte ohne diese Fehler stattfinden. Kein Post-Cutover-Notfall.

Das funktioniert, weil die Keyuser verstehen, was „falsch" ist — nicht weil sie Tester sind, sondern weil sie das Geschäft kennen.

Häufige Fehler beim Integrationstest im Mittelstand

Drei systematische Fehler verzögern Go-Lives um Monate und führen zu Produktions-Krisen.

Fehler 1: Die formale Test-Phase wird übersprungen. Der Druck ist groß — Go-Live ist terminiert. Integrationstest klingt aufwendig. Manche Implementierungs-Teams sagen: „Wir machen das im UAT" — aber UAT (User Acceptance Testing) testet, ob die Anforderung umgesetzt ist, nicht ob die Schnittstellen korrekt datenflussdicht sind. Das sind unterschiedliche Fragen. Sie benötigen beide Phasen. Wenn die formale Integrationstest-Phase ausfällt, werden Schnittstellenfehler erst nach dem Go-Live sichtbar — dann ist die Kostenintensität um ein Vielfaches höher.

Fehler 2: Manuelle Skalierung der Testmenge scheitert. Ein gutes Integrationstest-Szenario mit 10 Testfällen erscheint handhabbar. Dann kommt die Realität: Das System hat 47 Schnittstellen, nicht 10. Ein Team von 5 Keyusern kann nicht 470 Testfälle manuell durcharbeiten — nicht in 4 Wochen. Ohne Hybrid-Automation (Automation für Regression, manuelle Tests für Edge Cases) bricht dieser Ansatz zusammen.

Fehler 3: Vendor-Patch-Regressionen werden ignoriert. Der Integrationstest findet statt, läuft erfolgreich. Dann, zwei Wochen vor Go-Live, bringt der Vendor ein Security-Patch. Ein kritischer Fehler in der Finanzfunktion wird behoben. Das klingt gut — aber das Patch könnte eine Schnittstelle tangieren. Sie führen den Integrationstest nicht erneut aus? Das ist Risiko. Wir empfehlen: Regressions-Test-Suite ist lebend — bei jedem Patch wird sie erneut ausgeführt.

Was die meisten Integrationstest-Lehrbücher nicht erklären

Akademische Testmethodik und Mittelstands-Realität driften auseinander bei drei kritischen Punkten.

1. ISTQB-Definition vs. Mittelstandspraxis: Was ist Integrationstest wirklich?

ISTQB definiert Integrationstest als Prüfung von Schnittstellen zwischen Komponenten. Das ist technisch korrekt. Aber im Mittelstandskontext fehlt der Business-Impact: Integrationstest ist nicht nur: „Sendet System A das Datenpaket mit korrekter Syntax an System B?" — Es ist auch: „Wenn wir einen echten Kundenauftrag eingeben, wird er konsistent durch alle Module zum Geschäftsergebnis (Rechnungstellung) verarbeitet?"

Darum beruht Keyuser-basierter Integrationstest nicht auf technischem Detail-Wissen, sondern auf Geschäftsprozess-Verständnis. Ein Keyuser aus dem Vertrieb merkt sofort, wenn ein Preis falsch weitergegeben wird. Ein Finanzler merkt, wenn die Kostenstelle nicht übernommen wird. Das ist keine QA-Expertise — das ist Fachkenntnis. Und genau dort haben Mittelstands-Teams ihren Vorteil.

2. Ressourcen-Reality: QA-Teams existieren nicht im Mittelstand

ISTQB und die ISO/IEC/IEEE 29119-Reihe (die aktuelle internationale Norm für Software-Test-Dokumentation, die seit 2013 die ältere IEEE 829 abgelöst hat) unterstellen: Es gibt ein dediziertes QA-Team. Im Mittelstand haben Sie ein Team von Geschäftsnutzern, die nebenbei testen. Daraus folgt nicht, dass Sie weniger sorgfältig testen — es bedeutet, dass Sie pragmatische Automation brauchen.

Unsere Praxis: Rollen Sie nicht eine vollständige Test-Automation aus (zu teuer, zu lange). Automatisieren Sie stattdessen die wiederholbaren, hochfrequenten Tests (Stammdaten-Upload, Schnittstellen-Regression nach Patches). Die Business-Prozess-Tests führt das Keyuser-Team durch, weil die am besten validieren können, ob das Ergebnis „richtig" ist.

Und bei Multitenant-SaaS-Systemen (z. B. SAP S/4HANA Cloud): Sie können oft nicht in den System-Code schauen; Sie testen nur von außen. Das erfordert Black-Box-Testing-Disziplin, nicht White-Box-Automation.

3. Kontinuierliche Patches + Datenisolation: SaaS-ERP-Reality

Aus unserer Beratungspraxis: SaaS-ERP-Systeme erhalten Updates monatlich, manchmal wöchentlich. Jedes Update könnte eine Schnittstelle tangieren. On-Premise-Systeme hatten den Luxus: Patches einmal pro Halbjahr, geplant, getestet. Mit SaaS ist das vorbei.

Gleichzeitig fordert das deutsche NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) — in Kraft seit Dezember 2025, BSI-Registrierungspflicht bis März 2026 — dass Betreiber wesentlicher und wichtiger Einrichtungen Integrationstests dokumentiert und kontinuierlich verifiziert haben. Das ist nicht theoretisch — es ist seit Anfang 2026 geltende Compliance-Anforderung.

Mittelständler mit SaaS-ERP brauchen deswegen lebende Test-Szenarien, nicht einmalige Test-Kampagnen. Und weil in Multitenant-Systemen Daten zwischen Mandanten geteilt werden, ist Datenisolation und Maskierung keine reine Datenschutzpflicht, sondern eine Voraussetzung für Testintegrität.

Unsere Einordnung: Integrationstest ist nicht optional oder „nice-to-have" in modernen ERP-Implementierungen — es ist der Unterschied zwischen Go-Live-Erfolg und Post-Cutover-Notfall. Die Methodik muss zur Ressourcen-Realität des Mittelstands passen, nicht zu Konzern-Standard-Lehrbüchern.

Anwendung in DACH-Mittelstand-Verticals

Branchenspezifische Anforderungen verändern, welche Schnittstellen kritisch sind.

Maschinenbau: Kritische Schnittstellenflüsse sind Kalkulationen (Stücklistenexplosion), Terminplanung (Kapazitätsauslastung), Materialbereitstellung (Just-in-Sequence zur Montage). Integrationstests müssen Dezimal-Genauigkeit und Zeitkonsistenz validieren. Besonderheit: Kundenspezifische Anpassungen entstehen in jedem Projekt — die Testfall-Bibliothek muss dafür skalierbar sein.

Lebensmittelindustrie: Chargenverfolgung und Verfallsdatum-Management sind zentral. Integrationstests müssen prüfen: Batch-Nummern fließen konsistent durch alle Module, Verfallsdaten triggern automatisch Lagerbewegungen. Die EU-Lebensmittelinformationsverordnung (LMIV / VO 1169/2011) sowie HACCP-Prüfpflichten verlangen Allergen-Deklarationen und durchgängige Prüftrails.

Großhandel: Die Hauptschnittstelle ist Lagerverwaltung ↔ Kundensystem. Bei B2B-E-Commerce muss jedes Bestellupdate die Lagerverfügbarkeit in Echtzeit synchronisieren. Race Conditions sind hier häufig (zwei Kunden bestellen gleichzeitig, aber nur eine Einheit verfügbar). Integrationstests müssen Concurrency-Szenarios enthalten.

Nächste Schritte

Wenn Sie eine ERP-Implementierung planen, macht es Sinn, die Integrationstest-Methodik vor der Anforderungs-Phase zu skizzieren, nicht drei Wochen vor dem Go-Live. Das klingt früh, ist aber zentral: Je früher Sie klären, welche Schnittstellen kritisch sind und wie Sie diese testen, desto früher können Sie auch Automations-Tools auswählen und Testdaten vorbereiten.

Unsere Empfehlung: Laden Sie zu einem Integrationstest-Workshop mit Process Ownern, IT-Leitung und dem Operational-Excellence-Team ein. Kartografieren Sie in zwei Tagen die kritischen Datenflüsse. Daraus entsteht der Integrationstest-Plan — dieser wird Teil des Projektbudgets und der Timeline.

Matthias Müller und das Dreher-Team unterstützen Sie gerne bei diesem Workshop und der Methodik-Umsetzung. Aus über 50 Mittelstand-Projekten im DACH-Raum sehen wir konsistent: in jedem Projekt, in dem Integrationstest sauber gemacht wurde, war der Go-Live reibungslos. Das ist keine Prognose, das ist erlebte Praxis.

Matthias Müller
Senior Consultant Prozessoptimierung, ERP & Digitalisierung

Matthias begleitet Mittelstands-Unternehmen durch komplexe ERP-Implementierungen und ist auf die methodische Verzahnung von Prozessdesign und Systemauswahl spezialisiert.

Termin vereinbaren

Häufig gestellte Fragen

Wo endet Integrationstest und beginnt User Acceptance Testing (UAT)?

Integrationstest prüft die technische Datenflusskonsistenz zwischen Modulen und Systemen. UAT prüft, ob die Geschäftsanforderung erfüllt ist. Beispiel: Integrationstest validiert, dass eine Bestellung korrekt von Vertrieb ins Lager übertragen wird (technische Schnittstelle). UAT validiert, dass ein Vertriebler damit arbeiten kann und dass das Geschäftsergebnis passt. Beide sind notwendig, nicht konkurrierend.

Müssen wir Integrationstests nach jedem Vendor-Update erneut durchführen?

Ja — aber mit abgestuftem Aufwand. Nach kritischen Sicherheits-Patches (Security-Updates) führen Sie mindestens die Regression-Test-Suite erneut aus (automatisiert, schnell). Nach größeren Feature-Updates prüfen Sie, welche Module tangiert sind, und re-testen nur diese Schnittstellen. Nach Minor-Updates (Bugfixes, UI-Verbesserungen) kann eine oberflächliche Smoke-Test-Prüfung ausreichen — das hängt von der Risikobeurteilung Ihres Implementierungsteams ab.

Kann KI-gestützte Test-Automation den Integrationstest automatisieren?

KI-Tools sind in der Datenanalyse exzellent — Mustererkennung über mehrere ähnliche Projekte hinweg bleibt eine Beraterleistung. Bei Integrationstests: KI kann helfen, Testfall-Muster zu erkennen (z. B. „Alle Schnittstellen mit Dezimalfeldern sollten auf Rundungs-Edge-Cases getestet werden"). Aber die Definition, was „richtig" ist, kann KI nicht abnehmen — das braucht die DACH-Mittelstands-Realität-Interpretation, die ein Keyuser oder Berater mitbringt. Standardisierte KI-Antworten sind wertvoll für definitorische Fragen. Die ERP-spezifische Auslegung für Ihren Mittelständler fällt nicht in diese Kategorie.

Integrationstest in der ERP-Einführung — Methodik, Praxis und Erfolgsfaktoren