ERP-Tests müssen Geschäftsergebnisse prüfen, nicht Masken

Ein Key User legt einen Auftrag an, speichert ihn und setzt im Testprotokoll einen grünen Haken. Die Eingabemaske funktioniert. Ob Bestand reserviert, Preis und Steuer korrekt ermittelt, Kreditlimit beachtet, Lieferung erzeugt, Finanzbuchhaltung versorgt und die Schnittstelle genau einmal bedient wurde, bleibt ungeprüft.

ERP-Systeme bilden keine Sammlung unabhängiger Masken. Sie verbinden Regeln, Rollen, Stamm- und Bewegungsdaten sowie externe Systeme zu Geschäftsvorgängen. Ein Test ist deshalb erst aussagekräftig, wenn er das fachliche Ergebnis der gesamten relevanten Kette beurteilt.

Die entscheidende Frage lautet nicht: „Konnte jemand klicken?“ Sie lautet: „Entsteht unter normalen und schwierigen Bedingungen das richtige, nachvollziehbare Geschäftsergebnis?“

Der Prozess ist das Testobjekt

Ein ERP-Test sollte mit einem fachlichen Vorgang beginnen, nicht mit einem Modulnamen. „Vertrieb testen“ ist zu breit, „Auftrag mit lagerhaltigem Standardartikel vollständig bis zur korrekten Buchung und Auslieferung verarbeiten“ ist prüfbar.

Ein End-to-End-Test verbindet mindestens:

• fachlichen Auslöser und erwartetes Ergebnis,
• beteiligte Rollen und Berechtigungen,
• benötigte Stamm- und Bewegungsdaten,
• Geschäftsregeln und Freigaben,
• Statusübergänge und Folgebelege,
• ein- und ausgehende Schnittstellen,
• buchhalterische oder bestandsbezogene Wirkung,
• Protokolle und Nachweise,
• Behandlung von Fehlern, Korrektur und Wiederholung.

Das bedeutet nicht, dass jeder Test durch das gesamte Unternehmen laufen muss. Die Kette endet dort, wo das zu prüfende Risiko ausreichend beurteilt werden kann. Entscheidend ist, dass keine relevante Folge nur deshalb ausgeblendet wird, weil sie in einem anderen Modul oder System stattfindet.

Testfälle werden aus Risiken abgeleitet

Wenn Zeit und Fachpersonal begrenzt sind, darf nicht jeder Prozess gleich tief getestet werden. Die Priorität folgt der möglichen Wirkung eines Fehlers.

Hohe Testtiefe ist besonders sinnvoll bei Vorgängen, die:

• Umsatz, Zahlung, Bestand oder Abschluss direkt beeinflussen,
• große Mengen oder wiederkehrende Buchungen erzeugen,
• schwer rückgängig zu machen sind,
• sensible Berechtigungen oder Funktionstrennung betreffen,
• mehrere Schnittstellen durchlaufen,
• gesetzliche oder vertragliche Nachweise unterstützen,
• unter Zeitdruck oder zu festen Stichtagen ausgeführt werden,
• im Altverfahren viele manuelle Korrekturen benötigten.

Der ISTQB Foundation Level Syllabus v4.0.1 beschreibt, wie Produktrisiko die Testtiefe und den Testumfang beeinflussen kann. Das Dokument ist kein ERP-Einführungsleitfaden. Es liefert aber eine tragfähige Testlogik: Risiko bestimmt Priorität, nicht die Reihenfolge der Menüpunkte.

Der Normalfall beweist zu wenig

Ein korrektes Systemverhalten im einfachsten Fall sagt wenig über den betrieblichen Alltag aus. Kritische Fehler liegen häufig an Grenzen und Abweichungen.

Zu einer belastbaren Auswahl gehören daher:

• Mindest- und Höchstmengen,
• fehlende oder widersprüchliche Pflichtdaten,
• gesperrte Kunden, Lieferanten oder Artikel,
• Preis-, Steuer- und Währungsabweichungen,
• Teilmengen, Storno, Retoure und Gutschrift,
• Vertretung, fehlende Berechtigung und Vier-Augen-Freigabe,
• doppelte Übertragung oder zeitweise nicht erreichbare Schnittstelle,
• Periodenwechsel und Stichtage,
• nachträgliche Korrektur eines bereits weiterverarbeiteten Vorgangs,
• Wiederaufnahme nach technischem Abbruch.

Ausnahmen sollten nicht als Restliste am Ende behandelt werden. Der Beitrag „Der Ausnahmefall gehört in den Prozess – bevor er automatisiert wird“ zeigt, warum Ausnahmeentscheidungen bereits im Prozessdesign geklärt werden müssen. Im ERP-Test werden diese Entscheidungen praktisch überprüft.

Testdaten müssen Bedeutung tragen

Beliebige Beispieldaten können eine Maske füllen, aber keine fachliche Regel belegen. Ein Testkunde namens „Test Test“ besitzt meist weder reale Zahlungsbedingungen noch Steuerlogik, Lieferwege, Kreditlimit oder Beziehung zu den benötigten Belegen.

Ein kontrollierter Testdatenbestand sollte typische Datenklassen und kritische Kombinationen enthalten:

• verschiedene Kunden- und Lieferantengruppen,
• Artikel mit abweichender Disposition oder Bewertung,
• aktive, gesperrte und unvollständige Stammsätze,
• unterschiedliche Gesellschaften, Standorte oder Lager,
• Rollen mit erlaubten und ausdrücklich verbotenen Aktionen,
• offene Vorgänge für Migration und Periodenwechsel,
• eindeutig erwartbare Sollwerte für Bestände und Buchungen.

Produktionsdaten dürfen nicht unkontrolliert in eine Testumgebung kopiert werden. Personenbezug, Vertraulichkeit, Zugriff, Aufbewahrung und Löschung müssen für Testdaten ebenso geregelt sein. Anonymisierte oder synthetische Daten sind nur dann nützlich, wenn sie die fachlich relevanten Eigenschaften bewahren.

Das erwartete Ergebnis muss vor der Ausführung feststehen

Ein Test, dessen Ergebnis erst nach dem Klick diskutiert wird, misst eher Meinung als Systemverhalten. Vor der Ausführung werden deshalb Sollzustände festgelegt:

• erwarteter Status jedes relevanten Belegs,
• erwartete Menge, Preis, Steuer und Währung,
• erwartete Bestands- und Finanzbuchung,
• erwartete Nachricht an angebundene Systeme,
• erwartete Sichtbarkeit für Rollen,
• erwartete Fehlermeldung oder Sperre,
• erwarteter Audit- oder Protokolleintrag.

Der Qualitätsstandard ISO/IEC 25010:2023 stellt ein Modell für Produktqualität bereit, das unter anderem zur Definition von Testzielen und Abnahmekriterien verwendet werden kann. Für ein ERP bedeutet Qualität neben funktionaler Eignung beispielsweise auch Zuverlässigkeit, Sicherheit, Bedienbarkeit, Performance und Wartbarkeit. Ein fachlich richtiges Ergebnis, das nur mit einem unvertretbaren manuellen Aufwand erreichbar ist, kann betrieblich trotzdem ungeeignet sein.

Rückverfolgbarkeit verhindert grüne Lücken

Zwischen Prozessanforderung, Risiko, Testfall, Ergebnis und Fehler sollte eine nachvollziehbare Beziehung bestehen. Sonst ist zwar bekannt, wie viele Tests ausgeführt wurden, aber nicht, welche kritischen Anforderungen ungetestet blieben.

Eine einfache Matrix kann genügen:

Prozessrisiko oder Anforderung	Testfall	Ergebnis	Abweichung	Entscheidung
eindeutige Steuerermittlung	Verkauf Inland Standardfall	bestanden	keine	freigeben
keine Buchung ohne Freigabe	Auftrag oberhalb Freigabegrenze	fehlgeschlagen	Rolle kann Freigabe umgehen	Go-live blockieren
keine Doppelbuchung	Wiederholung nach Schnittstellenabbruch	offen	Testumgebung fehlt	Termin und Owner setzen

Die Anzahl grüner Testfälle ist ohne diese Abdeckung eine täuschende Kennzahl. Viele einfache Tests können bestanden sein, während ein einzelnes kritisches Risiko ungeprüft bleibt.

Konstruiertes Beispiel: Die Gutschrift trennt Lager und Finanzbuchhaltung

Das folgende Beispiel ist konstruiert.

Ein Projekt testet den Verkaufsprozess mit Standardaufträgen. Auftrag, Lieferschein und Rechnung funktionieren. Erst kurz vor dem Go-live prüft eine Fachanwenderin eine Teilretoure mit anschließender Gutschrift. Der Warenbestand wird korrigiert, die Gutschrift erreicht die Finanzbuchhaltung jedoch nicht, weil die betreffende Nachrichtenart in der Schnittstelle fehlt.

Jede einzelne Maske verhält sich plausibel. Das Geschäftsergebnis ist trotzdem widersprüchlich. Der Fehler wird nur sichtbar, weil der Test die Kette und ihre Sollbuchungen statt einzelne Funktionen betrachtet.

Die ERP-Testfallkarte

Eine kompakte Testfallkarte schafft gemeinsame Sprache zwischen Fachbereich, Projekt und IT.

Feld	Inhalt
Geschäftsziel	Welches fachliche Ergebnis soll entstehen?
Risiko	Welcher Fehler oder welche Abweichung soll erkannt werden?
Voraussetzungen	Rollen, Konfiguration, Stamm- und Ausgangsdaten
Auslöser	Ereignis oder Eingabe, mit der der Vorgang beginnt
Schritte	Wesentliche fachliche Aktionen ohne unnötige Klickdokumentation
Sollzustand	Belege, Status, Werte, Buchungen, Nachrichten und Protokolle
Kontrollpunkte	Wo und durch wen wird das Ergebnis geprüft?
Korrektur	Wie wird nach Fehler oder Abbruch weitergearbeitet?
Nachweis	Testdaten, Ausführungszeitpunkt, Ergebnis und Belegreferenzen
Verantwortung	fachlicher Tester, technische Unterstützung und Abnahmeentscheidung

Für wiederkehrende Tests kann die Karte automatisierte Prüfungen ergänzen. Automatisierung lohnt sich besonders bei stabilen, häufig ausgeführten Abläufen und klaren Sollwerten. Sie ersetzt nicht die fachliche Entscheidung, welche Risiken und Ausnahmen relevant sind.

Abnahme ist eine Entscheidung über Restrisiko

Ein ERP wird selten ohne offene Fehler produktiv gesetzt. Entscheidend ist, dass offene Punkte nach Wirkung bewertet werden:

• Welcher Prozess und welche Rollen sind betroffen?
• Gibt es einen kontrollierten und zumutbaren Umgehungsweg?
• Können Daten oder Buchungen dauerhaft falsch werden?
• Ist die Abweichung erkennbar und korrigierbar?
• Wer akzeptiert das Restrisiko bis wann?

Der Standard ISO/IEC/IEEE 29119-2:2021 beschreibt generische Testprozesse unabhängig vom Entwicklungsmodell. Im Mittelstand muss daraus kein schweres Testbüro entstehen. Notwendig bleiben aber Planung, nachvollziehbare Durchführung und eine bewusste Abschlussentscheidung.

Ein ERP-Test ist belastbar, wenn er dem Unternehmen nicht nur zeigt, dass Software reagiert. Er muss zeigen, ob relevante Geschäftsvorgänge unter realistischen Bedingungen richtige, vollständige und beherrschbare Ergebnisse erzeugen.