Tests in der ERP-Einführung
Welche Testarten eine ERP-Einführung braucht, wer sie durchführt und wann ein System abnahmereif ist
Stand: November 2026
Kernaussagen
- Getestet wird in der ERP-Einführung nicht die Standardsoftware, sondern ihre Einrichtung im eigenen Unternehmen: Prozesse, Daten, Schnittstellen und Berechtigungen [3]. Das kann nur das Projekt selbst prüfen.
- Die Testarten bauen aufeinander auf. Vom Funktionstest bis zum Abnahmetest wächst der geprüfte Ausschnitt, und die Verantwortung wandert vom Implementierungspartner zu den Fachbereichen [3].
- Abnahmereif ist ein System, wenn vorher vereinbarte Kriterien erfüllt sind. Fehlerfrei muss es dafür nicht sein [2], [4]. Wer die Kriterien erst in der Testphase festlegt, verhandelt sie unter Termindruck.
- Mit dem Go-Live endet das Testen nicht. Jedes Release eines Cloud-ERP verlangt Regressionstests der eigenen Kernprozesse [5], [6]; wie aufwendig sie werden, entscheidet sich schon in der Auswahl.
Als durchgehendes Beispiel dient ein Großhändler für Haustechnik, der ein neues ERP einführt. Sein wichtigster Prozess: Eine Bestellung kommt über den Webshop, das Lager kommissioniert und liefert, das ERP stellt die Rechnung und bucht sie in der Finanzbuchhaltung. An diesem Prozess zeigt die Seite, was jede Testart prüft.
Getestet wird die Einrichtung, abgenommen wird das Ergebnis
Test und Abnahme fallen im Projektalltag oft in einem Atemzug. Die Fachliteratur trennt sie: Ein Test sucht Fehler, die Abnahme ist eine Entscheidung. Vier Definitionen im Vergleich:
| Quelle | Begriff | Definition |
|---|---|---|
| ISTQB-Glossar, deutsche Fassung des German Testing Board [1] | Abnahmetest | „Eine Teststufe mit dem Schwerpunkt zu bestimmen, ob ein System abgenommen werden kann.“ |
| Gabler Wirtschaftslexikon [2] | Testen, Abnahmetest | Zweck des Testens ist das „Aufspüren und Beseitigen von Fehlern, nicht aber der Nachweis der Korrektheit“. Der Abnahmetest ist die „Überprüfung des Softwareprodukts durch den Auftraggeber, i.Allg. auf Basis des Pflichtenheftes“. |
| Microsoft, Leitfaden für Dynamics-365-Einführungen [4] | Freigabe nach dem User Acceptance Test | Die Freigabe bedeutet nach Microsoft nicht, dass die Lösung perfekt oder fehlerfrei ist. Sie bedeutet, dass die Lösung gut genug ist, um das Geschäft sicher und effizient zu betreiben (übersetzt). |
| Bürgerliches Gesetzbuch, § 640 [7] | Abnahme beim Werkvertrag | Der Besteller ist verpflichtet, das vertragsmäßig hergestellte Werk abzunehmen. „Wegen unwesentlicher Mängel kann die Abnahme nicht verweigert werden.“ |
Gemeinsam ist allen vier Definitionen ein Maßstab, gegen den geprüft wird: das Pflichtenheft, vereinbarte Kriterien oder der Vertrag. Unterschiedlich ist, wer entscheidet und mit welcher Folge. Ob eine Abnahme im Rechtssinn geschuldet ist und was sie auslöst, hängt vom Vertragstyp ab und gehört in den Vertrag mit dem Implementierungspartner.
Unser Verständnis
Tests in der ERP-Einführung prüfen, ob das eingerichtete System mit den eigenen Daten und Rollen die vereinbarten Prozesse trägt. Die Abnahme ist die Entscheidung der Fachbereiche, dass es dafür gut genug ist, gemessen an Kriterien, die vor dem ersten Test feststehen.
Zwei Begriffe werden dabei anders gebraucht als in der Testliteratur. Mit „Modultest“ meinen ERP-Projekte meist den Test eines ERP-Moduls wie Einkauf oder Vertrieb; in der Softwareentwicklung ist es der Test eines einzelnen Programmbausteins [2]. Der Integrationstest einer ERP-Einführung spielt ganze Geschäftsprozesse über Module und angebundene Systeme durch. Das ISTQB-Glossar führt das als Ende-zu-Ende-Test und Systemintegrationstest, sein Integrationstest meint enger das Zusammenwirken von Komponenten [1]. Klären Sie die Begriffe zu Projektbeginn, damit Partner und Fachbereiche im Testplan dasselbe meinen.
Nicht gemeint sind Tests in der Auswahl, etwa ein Proof of Concept. Dort wird geprüft, ob ein System infrage kommt; hier, ob das eingeführte System trägt.
Die Testphase der ERP-Einführung führt in fünf Stufen zur Abnahme
In der Testphase einer ERP-Einführung wiederholen sich wenige Testarten in festen Rollen. Sie unterscheiden sich darin, was sie prüfen, mit welchen Daten und wer testet. Jede setzt voraus, dass die vorige bestanden ist: Ein Fehler, den der Funktionstest übersieht, taucht sonst im Integrationstest auf, wo er schwerer einzugrenzen ist. Die Übersicht am Beispiel des Großhändlers:
| Testart | Was geprüft wird | Im Beispiel | Wer testet |
|---|---|---|---|
| Funktionstest | einzelne Funktionen und Einstellungen eines Moduls | Preisfindung mit Staffelpreis und Kundenrabatt, Anlage eines Auftrags | Implementierungspartner, danach Key User |
| Testmigration | Übernahme der Altdaten: vollständig, plausibel, richtig verknüpft | Kundenstamm mit Zahlungsbedingungen, offene Aufträge, Lagerbestände | Partner oder IT, fachliche Prüfung durch die Datenverantwortlichen |
| Integrationstest | ganze Prozesse über Module und angebundene Systeme | Bestellung aus dem Webshop bis zur Buchung, Lieferstatus zurück an den Shop | Partner bereitet vor, Key User testen |
| Last- und Performanztest | Antwortzeiten und Laufzeiten unter Spitzenlast | Auftragseingang an Spitzentagen, Rechnungslauf am Monatsende | Partner und IT mit Key Usern |
| Abnahmetest | ob die Fachbereiche ihre Arbeit mit dem System erledigen können | Innendienst, Lager und Buchhaltung spielen typische Arbeitstage mit migrierten Daten durch | Key User und Fachbereiche |
| Regressionstest | ob nach einer Änderung Bestehendes noch funktioniert | Preisfindung und Shop-Schnittstelle nach einem Release | Key User, zunehmend automatisiert |
Beispiel zur Veranschaulichung. Rollen nach [3] und den Erfahrungen von Find-Your-ERP.
Die Reihenfolge beschreibt Schwerpunkte, keine starre Abfolge. Testmigrationen beginnen früh und laufen mehrfach. Performanztests sollten nach Microsofts Empfehlung ebenfalls früh starten, weil ihre Befunde die Architektur betreffen können [3]. Warum ein spät entdeckter Fehler teurer wird, rechnet find-your-software.de am Beispiel der Änderungskosten vor.
Funktions- und Integrationstest prüfen erst die Einrichtung, dann den Prozess
Im Funktionstest prüft der Implementierungspartner zuerst seine eigene Einrichtung. Microsoft empfiehlt diese Reihenfolge, damit die Lösung stabil ist, wenn der Fachbereich sie zum ersten Mal sieht [3]. Für den Großhändler heißt das: Die Preisfindung rechnet Staffelpreise und Rabatte richtig, bevor jemand eine Bestellung aus dem Shop durchspielt.
Der Integrationstest verbindet die Funktionen zum Prozess. Er findet die Fehler, die zwischen Modulen und Systemen liegen: eine Lieferung, die der Shop nicht als versendet meldet, eine Rechnung auf dem falschen Erlöskonto, eine Berechtigung, die dem Lager eine Buchung verwehrt. Dafür braucht er realistische Daten, Rollen mit den späteren Berechtigungen und die angebundenen Systeme in einer Testumgebung. Eine simulierte Schnittstelle zeigt Formatfehler, das Verhalten im Ablauf zeigt sie nicht. Microsoft rät zu mehreren Durchläufen, weil ein einziger am Ende zu wenig Zeit für Korrekturen lässt [3].
Die Testmigration zeigt, ob das System mit den eigenen Daten arbeitet
Eine Testmigration, auch Probemigration genannt, übernimmt die Altdaten in eine Testumgebung und prüft sie dort. Mit wenigen idealen Beispieldatensätzen ist sie wenig wert. Sie braucht echte Datenmengen mit problematischen Datensätzen und Sonderfällen, und meist mehrere Läufe: Der erste zeigt Fehler, der zweite prüft die Korrekturen (siehe Datenmigration im ERP-Projekt). Technisch wird über Satzzahlen und Summen geprüft, fachlich über Stichproben der Datenverantwortlichen. Im Beispiel zeigt sich dabei, ob jeder Kunde seine Zahlungsbedingung behalten hat und ob die Bestände je Lagerplatz stimmen.
Die Testmigration ist zugleich Voraussetzung für die späteren Stufen. Integrations- und Abnahmetest brauchen migrierte Daten, weil Altdaten andere Muster haben als Demodaten [3].
Last- und Performanztests gehören in die Planung
Ein Lasttest prüft das Verhalten eines Systems unter wechselnder Last, von niedriger über typische bis zur Spitzenlast [1]. Im ERP betrifft das zwei Fälle: viele Anwender oder Belege gleichzeitig und lange Stapelläufe wie Rechnungslauf oder Monatsabschluss. Microsoft zählt die Performanz zu den größten Risiken in Einführungsprojekten, weil sie oft übersehen oder unterschätzt wird. Sie hängt an Daten, Einrichtung und Erweiterungen ebenso wie an der Infrastruktur [3].
Für den Großhändler zählen der Auftragseingang an Spitzentagen und die Dauer des Rechnungslaufs am Monatsende. Welche Antwortzeit noch akzeptabel ist, legt der Fachbereich vor dem Test fest; sonst lässt sich das Ergebnis nicht bewerten.
Im Abnahmetest spielen die Fachbereiche ihren Arbeitsalltag durch
Der Abnahmetest ist die letzte Teststufe vor dem Produktivstart. Das ISTQB-Glossar unterscheidet den Benutzerabnahmetest, in dem die künftigen Anwender abnehmen, vom betrieblichen Abnahmetest, in dem die für den Betrieb verantwortliche Organisation abnimmt [1]. Im ERP-Projekt sind beide nötig. Der Innendienst prüft, ob er Aufträge vollständig bearbeiten kann. Die IT prüft Datensicherung und die Überwachung der Schnittstellen.
Getestet wird mit migrierten Daten in einer integrierten Testumgebung, die dem Echtbetrieb möglichst nahekommt, und die Testenden sind vorher geschult [3]. Der Abnahmetest ersetzt keine Schulung: Wer das System im Test zum ersten Mal sieht, meldet Bedienfragen als Fehler.
Kurz vor dem Go-Live folgt oft eine Generalprobe des Cutovers in der Produktivumgebung. Sie prüft Reihenfolge und Dauer der Umstellungsschritte [3]. Was zur Umstellung selbst gehört, steht im Glossar unter Cutover.
Abnahmereif ist ein System, wenn vereinbarte Kriterien erfüllt sind
Ein häufiger Irrtum lautet, ein System sei erst abnahmereif, wenn es fehlerfrei ist. Ein ERP-System geht praktisch nie ohne offene Fehler in Betrieb, und Testen kann Fehler finden, ihre Abwesenheit aber nicht beweisen [2]. Entscheidend ist deshalb, welche Fehler noch offen sind.
Dafür braucht die Abnahme Akzeptanzkriterien, also Kriterien, die ein Ergebnis erfüllen muss, damit die Beteiligten es akzeptieren [1]. Bewährt hat sich, sie mit Fehlerklassen zu verbinden und beides vor dem ersten Abnahmetest festzuschreiben, am besten schon im Vertrag mit dem Implementierungspartner:
| Fehlerklasse | Beschreibung | Folge für die Abnahme |
|---|---|---|
| kritisch | Ein Kernprozess steht, und es gibt keine Umgehung. Im Beispiel: Bestellungen aus dem Webshop kommen nicht im ERP an | verhindert die Abnahme |
| schwer | Der Prozess läuft nur mit Umgehung oder Mehraufwand. Im Beispiel: Rabatte müssen von Hand nachgetragen werden | Abnahme nur mit dokumentierter Umgehung und Termin für die Behebung |
| leicht | Darstellung, Bedienkomfort, seltene Sonderfälle | Behebung nach dem Go-Live |
Beispiel einer Einteilung; Bezeichnungen und Grenzen legt jedes Projekt selbst fest.
Nach jeder Behebung bestätigt ein Fehlernachtest, dass der Fehler nicht mehr auftritt [1]. Korrekturen kurz vor dem Termin verlangen zusätzlich einen Regressionstest der betroffenen Prozesse. Microsoft rät, bei spät gefundenen Fehlern den Nutzen der Korrektur gegen das Risiko abzuwägen, sie nicht mehr ausreichend testen zu können [3].
Die Abnahme der Fachbereiche ist die Grundlage der Go-Live-Entscheidung, aber noch nicht die Entscheidung selbst. Sie fällt im Lenkungskreis, der zusätzlich den Stand von Datenmigration und Schulung im Blick hat. Mehr zum Produktivstart steht im Glossar unter Go-Live.
Partner, Key User und Fachbereiche tragen je Stufe eine andere Verantwortung
Testen gilt in manchen Projekten als Aufgabe der IT oder des Partners. Technisch läuft dort vieles zusammen, fachlich beurteilen kann ein Testergebnis nur, wer den Prozess kennt. Der Implementierungspartner richtet ein, testet seine Einrichtung zuerst selbst und bereitet die Testfälle der späteren Stufen vor [3]. Die Key User bringen die Abläufe ihres Bereichs mit allen Sonderfällen ein, führen Integrations- und Abnahmetests durch, melden Abweichungen und geben ihren Bereich formal für den Go-Live frei (siehe Key User im ERP-Projekt). Die Leitung des Fachbereichs verantwortet die Abnahme für ihren Bereich. Ein Testmanagement beim Partner oder im eigenen Projektteam hält Testkonzept und Fehlerliste zusammen.
Ein typischer Engpass ist die Zeit der Key User. Testphasen fallen in dieselben Wochen wie Schulung, Datenbereinigung und das laufende Geschäft. Ohne vereinbarte Freistellung verdrängt die Linie das Projekt genau dann, wenn die Tests die meiste Aufmerksamkeit brauchen.
Nach dem Go-Live sichern Regressionstests jedes Release ab
Ein verbreiteter Irrtum lautet, der Hersteller habe seine Software getestet, also genüge nach einem Update ein kurzer Blick. Microsoft testet seine Updates, hält aber fest, dass Datenbestand, Einrichtung und Erweiterungen jedes Kunden eigene Regressionstests in dessen Umgebung verlangen [5]. Ein Regressionstest prüft, ob in unveränderten Bereichen durch eine Änderung Fehler entstanden oder sichtbar geworden sind [1].
Bei Cloud-ERP bestimmt der Hersteller den Takt. Business Central erhält zum Beispiel zwei große Updates im Jahr, im April und im Oktober. Microsoft empfiehlt, kritische Geschäftsszenarien vorher zu testen, in einer Vorschauumgebung und an einer Kopie der Produktivdaten [6]. Wer seine Kernprozesse nur von Hand testen kann, bindet die Key User bei jedem Release für Tage. Deshalb lohnt es, die Testfälle aus Integrations- und Abnahmetest als Regressionspaket aufzubewahren und Schritt für Schritt zu automatisieren, beginnend bei den geschäftskritischen Prozessen [3].
Je mehr Anpassungen ein System trägt, desto größer wird dieses Paket; jede Anpassung erhöht den Aufwand bei jedem Update (siehe Glossar, Customizing). Beim Großhändler gehören Preisfindung, Shop-Schnittstelle und Rechnungslauf in jeden Regressionstest.
In der Auswahl entscheidet sich, wie aufwendig das Testen wird
Der Testaufwand fällt in der Einführung an, festgelegt wird er in der Auswahl: mit dem Umfang der Anpassungen, dem Release-Takt des Systems und dem Angebot des Implementierungspartners. Fragen Sie deshalb vor der Entscheidung nach:
| Prüffrage | Woran Sie eine gute Antwort erkennen |
|---|---|
| Welche Testumgebungen gehören zum Angebot? | Mindestens eine integrierte Testumgebung neben der Produktivumgebung, die sich mit einer Kopie der Produktivdaten füllen lässt |
| Wie oft kommen Releases, und wie früh lassen sie sich testen? | Fester Release-Takt, Vorschauversion vor dem Update, selbst gewähltes Wartungsfenster |
| Wie lassen sich Regressionstests automatisieren? | Der Anbieter zeigt ein Werkzeug an einem Ihrer Prozesse, statt es nur zu erwähnen |
| Welche Tests übernimmt der Implementierungspartner? | Testkonzept, Funktionstests, Vorbereitung der Testfälle und die Zahl der Testmigrationen stehen im Angebot |
| Wie sind Abnahme und Fehlerklassen geregelt? | Akzeptanzkriterien und Fehlerklassen sind im Vertrag oder im Pflichtenheft beschrieben |
| Wie viele Anpassungen braucht die Lösung? | Jede Anpassung ist im Angebot benannt, denn jede gehört in den Regressionstest |
| Wie viel Zeit brauchen die Key User? | Der Partner nennt den Aufwand der Fachbereiche je Testphase |
Was einen Implementierungspartner ausmacht, steht im Glossar unter Implementierungspartner.
Häufige Fragen
Was gehört in einen Testfall?
Nach dem ISTQB-Glossar besteht ein Testfall aus Vorbedingungen, Eingaben, Aktionen, erwarteten Ergebnissen und Nachbedingungen [1]. Im Beispiel: Ein Kunde mit Staffelpreis und zehn Prozent Rabatt ist angelegt (Vorbedingung), er bestellt 50 Stück im Webshop (Eingabe), und der Auftrag kommt mit dem richtigen Nettopreis im ERP an (erwartetes Ergebnis). Ohne erwartetes Ergebnis lässt sich ein Test nicht als bestanden oder nicht bestanden bewerten.
Brauchen wir eine eigene Testumgebung?
In der Regel mehrere. Microsoft sieht für den Abnahmetest eine eigene, integrierte Testumgebung vor, für Performanztests eine leistungsfähige Umgebung, die nicht während des ganzen Projekts bereitstehen muss, und für die Generalprobe des Cutovers die Produktivumgebung [3]. Enthält eine Testumgebung eine Kopie der Produktivdaten, gelten für sie dieselben Datenschutzanforderungen wie für das Produktivsystem.
Was ist ein Testkonzept?
Das Testkonzept dokumentiert die Testziele sowie die Mittel und die Zeitplanung, um sie zu erreichen [1]. In der ERP-Einführung legt es fest, welche Prozesse in welcher Testart geprüft werden, wer testet, in welcher Umgebung, mit welchen Daten und nach welchen Kriterien ein Testzyklus beginnt und endet [4]. Es entsteht vor dem ersten Test.
Lohnt sich Testautomatisierung schon während der Einführung?
Für die Kernprozesse meist ja. Microsoft empfiehlt, automatisierte Tests so früh wie möglich aufzubauen, zuerst für die wichtigsten Geschäftsprozesse [3]. Automatisiert wird, was sich wiederholt, vor allem die Regressionstests nach Korrekturen und Releases. Den Abnahmetest ersetzt Automatisierung nicht, weil dort Menschen beurteilen, ob sie mit dem System arbeiten können; Microsoft sieht ihn ausdrücklich als manuellen Test [3].
Weiterlesen
Warum Key User über Akzeptanz und Go-Live mitentscheiden und woran eine schwache Besetzung früh erkennbar ist.
Welche Daten ins neue System gehören, wie Sie sie vorher bereinigen und den Go-Live absichern.
Wann eine Anpassung des Systems gerechtfertigt ist und wann sich der Prozess ändern sollte.
Wie wir Einführungen herstellerneutral begleiten, von der Vorbereitung über Tests und Schulung bis zur Stabilisierung.
Die Kurzdefinitionen zu Testphase, Key User, Cutover, Go-Live und Hypercare.
Quellen
[1] ISTQB und German Testing Board: ISTQB-Glossar, deutsche Fassung, Einträge Abnahmetest, Benutzerabnahmetest, betrieblicher Abnahmetest, Integrationstest, Systemintegrationstest, Ende-zu-Ende-Test, Lasttest, Regressionstest, Fehlernachtest, Akzeptanzkriterien, Testfall, Testkonzept. Abgerufen am 9. November 2026.
[2] Lackes, R.: Testen. Gabler Wirtschaftslexikon. Abgerufen am 9. November 2026.
[3] Microsoft: Types of tests that implementation projects use. Dynamics 365 Implementation Guide, Microsoft Learn (englisch), Stand 23. Januar 2024.
[4] Microsoft: Test your Dynamics 365 solution before deployment. Dynamics 365 Implementation Guide, Microsoft Learn (englisch), Stand 7. Januar 2025.
[5] Microsoft: Options for regression testing for Dynamics 365 solutions. Dynamics 365 Implementation Guide, Microsoft Learn (englisch), Stand 12. Dezember 2025.
[6] Microsoft: Update cycles. Dokumentation Dynamics 365 Business Central, Microsoft Learn (englisch), Stand 8. Oktober 2026.
[7] § 640 BGB, Abnahme. Bürgerliches Gesetzbuch, gesetze-im-internet.de. Abgerufen am 9. November 2026.
Die Herstellerdokumentation belegt allgemeine Prinzipien und ist keine Produktempfehlung.
Dr. Benedict Bender
Co-Founder der Sectorlens GmbH
Besprechen Sie Ihr Testkonzept mit einem ERP-Berater
Im Gespräch klären Sie mit einem Berater, welche Tests Ihre Einführung braucht und wie Sie Abnahmekriterien mit dem Implementierungspartner festlegen. 30 Minuten, kostenlos und unverbindlich. Anbieterneutral: Kein Anbieter kann seine Platzierung kaufen oder beeinflussen.
Sie haben eine Frage? Dann schicken Sie uns gern eine Nachricht.