Testplan und Testfälle für die ERP-Einführung aus Ihren Prozessen
Kurz gesagt
Das Vorgehen gilt für Betriebe in Deutschland, Österreich und der Schweiz. Leiten Sie aus jedem Schritt Ihrer Sollprozesse mindestens einen Normalfall, einen Grenzfall und einen Fehlerfall ab, nummerieren Sie die Fälle und halten Sie das erwartete Ergebnis vor dem Lauf fest. Als Grundstock dienen 25 Standardfälle von Auftrag bis Zahlung, Bestellung bis Zahlung, Monatsabschluss und Querschnitt.
Das Wichtigste
- Je Schritt des Sollprozesses mindestens ein Normalfall, ein Grenzfall und ein Fehlerfall.
- 25 Standardfälle zum Anpassen: Auftrag bis Zahlung (9), Bestellung bis Zahlung (7), Monatsabschluss (6), Querschnitt (3).
- Erwartetes Ergebnis vor dem Lauf festhalten; Ist-Ergebnis mit Nachweis, Version und Datum je Fall protokollieren.
- ISO/IEC/IEEE 29119-2:2021 (Ausgabe 2.0, 28. Oktober 2021) beschreibt Testprozesse; die Norm bindet nicht durch Gesetz.
- Der Lehrplan ISTQB Certified Tester Foundation Level (CTFL) v4.0.1 (freigegeben 15. September 2024) beschreibt Testaktivitäten, Verfahren, Testplan und Kriterien.
Ein Testfall ist ein Vorgang mit einem vorher festgeschriebenen erwarteten Ergebnis. Im ERP-Projekt entsteht er nicht am Schreibtisch der IT allein, sondern aus einem Schritt Ihres Sollprozesses: Der Prozessschritt sagt, was geschehen soll, der Testfall sagt, woran Sie erkennen, dass es geschehen ist. Dieses Vorgehen liefert drei Teile: den Weg vom Prozessschritt zum Fall, eine Vorlage für jeden Fall und 25 Standardfälle als Grundstock.
Was Sie vorab brauchen
- die abgezeichneten Sollprozesse mit ihren Schritten und dem Ergebnis je Prozess
- die Liste der Teststufen, auf denen Sie testen: Prozesstest, Schnittstellentest, Datenübernahmetest, Abnahmetest
- ein Testsystem ohne Verbindung zur Produktivdatenbank, mit abgeschalteten Schnittstellen für Mail, Bank und Shop
- Testdaten je Fall: ein Kunde, ein Lieferant, ein Artikel, ein Konto, eine offene Periode, etwa aus einem geladenen Probeexport
- die Testfallvorlage aus diesem Artikel, einmal je Prozess und fortlaufend nummeriert
- ein Protokollblatt, in dem Ist-Ergebnis, Nachweis, Version und Datum je Fall stehen
- eine Fehlerliste mit laufender Nummer, Zuständigem und Termin, in die jeder fehlgeschlagene Fall wandert
- zwei Personen: eine führt aus, eine prüft und protokolliert
Schritt für Schritt: vom Prozess zum geprüften Testfall
Der Lehrplan beschreibt den Testprozess in Aktivitäten: Planung, Überwachung und Steuerung, Analyse, Entwurf, Umsetzung, Ausführung und Abschluss (Abschnitt 1.4.1); für weitere Angaben verweist er auf ISO/IEC/IEEE 29119-2. Die sieben Schritte unten ordnen sie einer ERP-Einführung zu.
Schritt 1: Testumfang und Teststufen festlegen
Notieren Sie, welche Prozesse geprüft werden und auf welcher Stufe. Auswahlregel dieses Artikels: ein Prozess ist im Umfang, wenn er einen Beleg erzeugt, einen Bestand verändert oder in die Buchhaltung führt. Das sind Auftrag bis Zahlung, Bestellung bis Zahlung und der Monatsabschluss; dazu kommen die Schnittstellen zu Nachbarsystemen und die Datenübernahme. Ende: die Liste der Prozesse und Teststufen liegt schriftlich vor.
Schritt 2: Testbedingungen aus den Prozessschritten ableiten
Gehen Sie Ihre Sollprozesse Schritt für Schritt durch und formulieren Sie je Schritt eine prüfbare Bedingung aus Handlung, Eingabe und erwartetem Ergebnis. Aus dem Schritt „Kreditlimit prüfen“ wird die Bedingung „Ein Auftrag über dem Limit wird ohne Freigabe nicht ausgelöst“. Ein Schritt ohne prüfbare Bedingung ist zu grob beschrieben; klären Sie ihn mit der fachlich verantwortlichen Person. Ende: je Prozessschritt steht mindestens eine Bedingung in der Liste.
Schritt 3: Fälle bilden – Normalfall, Grenzfall, Fehlerfall
Zu jeder Bedingung gehören mindestens drei Fälle: der Normalfall mit gültigen Werten, ein Grenzfall an der Grenze der Bedingung und ein Fehlerfall mit ungültigen Werten. Für die Auswahl der Werte nennt der Lehrplan vier Verfahren (Abschnitt 4.2): bei Äquivalenzklassen genügt ein Wert je Klasse, weil das System alle Werte einer Klasse gleich behandeln soll; bei geordneten Werten prüft die Grenzwertanalyse die Grenze und den benachbarten Wert; eine Entscheidungstabelle spielt Kombinationen mehrerer Bedingungen durch; ein Zustandsübergangstest prüft Abläufe mit Status wie offen, teilgeliefert, gesperrt und bezahlt.
Beispielrechnung mit erfundenen Zahlen: Das Kreditlimit eines Kunden liegt bei 5.000 Euro. Der Normalfall nutzt 4.000 Euro, der Grenzfall genau 5.000 Euro, der Fehlerfall 5.001 Euro und zusätzlich eine Freigabe durch die berechtigte Rolle.
Schritt 4: Testdaten und Testsystem bereiten
Legen Sie je Fall fest, welche Datensätze er braucht, und legen Sie sie im Testsystem an, bevor Sie starten. Prüfen Sie, dass das Testsystem keine Verbindung zur Produktivdatenbank hat und keine Nachrichten oder Zahlungsaufträge nach außen schickt. Als Projektregel dieses Artikels gilt: keine unveränderten Kundendaten kopieren, sondern selbst angelegte oder anonymisierte Testdaten nutzen; die Zulässigkeit klären Sie mit Ihrer Datenschutzberatung. Ende: jeder Fall findet seine Daten vor.
Schritt 5: Reihenfolge festlegen und priorisieren
Fälle bauen aufeinander auf: Der Zahlungseingang braucht eine offene Rechnung, der Dreifachabgleich eine Bestellung mit Wareneingang. Notieren Sie diese Abhängigkeiten und ordnen Sie die Fälle danach. Der Lehrplan nennt drei Strategien für die Reihenfolge (Abschnitt 5.1.5): Risiko, Abdeckung und Anforderungspriorität; nach der risikoorientierten Strategie laufen die Fälle mit dem höchsten Risiko zuerst. Ende: die Ausführungsreihenfolge steht mit Datum.
Schritt 6: Ein- und Austrittskriterien festlegen
Legen Sie vor dem Lauf fest, wann er beginnt und wann er gilt. Der Lehrplan nennt als typische Eintrittskriterien verfügbare Mittel und Testware sowie einen Anfangszustand des Testobjekts (Abschnitt 5.1.3), für Ihr Projekt etwa: Testsystem erreichbar, Stammdaten geladen, Periode offen, Fälle abgezeichnet. Typische Austrittskriterien sind erreichte Abdeckung, Zahl offener Fehler und geplante, aber nicht ausgeführte Fälle. Die Abnahme entscheiden Sie danach nach dem Abnahmetest im ERP-Projekt. Ende: beide Kriterienlisten sind abgezeichnet.
Schritt 7: Ausführen und protokollieren
Führen Sie die Fälle in der festgelegten Reihenfolge aus, tragen Sie das Ist-Ergebnis mit Datum, Version und Nachweis ein und halten Sie Abweichungen mit Nummer und Datum in der Fehlerliste fest. Als Inhalt eines Fehlerberichts nennt der Lehrplan unter anderem eine eindeutige Nummer, Datum und Testumgebung, den Zusammenhang mit dem Testfall, die Schritte zur Wiederholung, erwartetes und tatsächliches Ergebnis, Schweregrad, Priorität und Status (Abschnitt 5.5). Ende: jeder Fall hat einen Status, jeder offene Punkt eine zuständige Person und einen Termin.
Der Aufbau des Testplans
Der Testplan hält den Testrahmen fest; die Fälle hängen an ihm. Der Lehrplan nennt als typischen Inhalt (Abschnitt 5.1.1):
- Kontext: Umfang, Ziele und Testbasis, also die abgezeichneten Sollprozesse, die Anforderungen und die Altdaten
- Annahmen und Grenzen: was vorausgesetzt wird, was ausdrücklich nicht im Umfang liegt
- Beteiligte: Rollen, Verantwortlichkeiten und wer welche Fälle ausführt
- Kommunikation: Form und Häufigkeit der Abstimmung, Vorlagen für Protokoll und Fehlerliste
- Risiken: je Risiko die Auswirkung, die Eintrittswahrscheinlichkeit und die geplante Prüfung
- Testansatz: Teststufen, Testverfahren, Ein- und Austrittskriterien, Testdaten, Testumgebung und Kennzahlen
- Budget und Termin: Testtage, Zeitfenster und Belegung der Key User
Je Punkt genügt ein Absatz. Den Testplan zeichnet die Projektleitung ab, die Testfälle die fachlich verantwortliche Person; die Rollen im Projekt stehen im Artikel zu den Projektrollen bei der ERP-Einführung.
Die Testfall-Vorlage
Die Vorlage ist eine Festlegung dieses Artikels, die Beispielwerte sind erfunden. Vor dem Lauf sind alle Felder gefüllt; Ist-Ergebnis, Status und Fehlernummer entstehen nach der Ausführung.
| Feld | Inhalt | Beispiel (erfunden) |
|---|---|---|
| Testfall-Nr. | fortlaufende Nummer aus der Fallliste, je Prozess und Gruppe | 5 |
| Prozess und Schritt | Sollprozess und der Schritt, aus dem der Fall stammt | Auftrag bis Zahlung, Schritt Rechnung stellen |
| Testbedingung | was geprüft wird, in einem Satz mit erwartetem Ergebnis | Die Rechnung übernimmt Rabatt und Zahlungsziel aus dem Auftrag |
| Teststufe | Prozesstest, Schnittstellentest, Datenübernahmetest oder Abnahmetest | Prozesstest |
| Vorbedingungen | Daten, Rolle und Systemzustand vor dem Lauf | Auftrag 4711 mit 10 Prozent Rabatt, Periode offen, Rolle Vertrieb |
| Eingaben | Werte und Datensätze mit Einheit | Kunde 10042, Artikel A-118, Menge 12, Stückpreis 99,00 Euro |
| Schritte | Handlungen in der Reihenfolge der Ausführung | Auftrag öffnen, Rechnung erzeugen, Beleg prüfen |
| Erwartetes Ergebnis | prüfbare Werte mit Einheit | 1.069,20 Euro netto (12 × 99,00 = 1.188,00 Euro, minus 10 Prozent), Zahlungsziel 30 Tage |
| Nachweis | woran das Ergebnis belegt wird | Rechnungsnummer 2026-0815, Ausdruck, Protokollzeile 12 |
| Ist-Ergebnis und Status | bestanden, fehlgeschlagen, blockiert oder offen | bestanden |
| Fehlernummer | Verweis in die Fehlerliste | F-012 |
| Bearbeiter und Datum | wer wann ausgeführt hat | K. Muster, 12.10.2026 |
| Version und Testsystem | getesteter Stand und Name des Testsystems | Release 3.2, Testmandant 2 |
25 Standard-Testfälle zum Anpassen
Die folgenden Fälle sind eine Auswahl dieses Artikels, keine Normvorgabe. Jeder Fall läuft Ende-zu-Ende über mehrere Stationen und endet mit einem Nachweis. Passen Sie Bezeichnungen, Rollen und Nummernkreise an; streichen Sie einen Fall nur mit Begründung und Ersatz.
Auftrag bis Zahlung (Order to Cash)
| Nr. | Testfall | Erwartetes Ergebnis |
|---|---|---|
| 1 | Angebot in Auftrag überführen | Positionen, Preise, Rabatt und Zahlungsziel werden unverändert übernommen |
| 2 | Auftrag an der Kreditlimitgrenze freigeben | Über dem Limit wird ohne Freigabe nicht ausgelöst; die Freigabe durch die berechtigte Rolle setzt den Vorgang fort |
| 3 | Auftrag mit Teillieferung abwickeln | Zwei Lieferscheine erzeugen; Restmenge und Auftragsstatus stimmen nach dem zweiten |
| 4 | Lieferschein mit Lagerentnahme buchen | Bestand sinkt um die gelieferte Menge, die Reservierung wird um dieselbe Menge freigegeben |
| 5 | Rechnung aus dem Auftrag stellen | Positionssummen, Rabatt, Fracht und Steuerschlüssel entsprechen dem Auftrag, die Nummer folgt dem Nummernkreis |
| 6 | Rechnung stornieren oder gutschreiben | Gegenbeleg mit eigener Nummer; offener Posten und Umsatz sind ausgeglichen |
| 7 | Zahlungseingang aus dem Kontoauszug zuordnen | Die Rechnung ist ausgeglichen, der offene Posten verschwindet, die Zuordnung ist belegt |
| 8 | Teilzahlung mit Skonto buchen | Die Restforderung bleibt offen, der Skontobetrag steht auf dem dafür vorgesehenen Konto |
| 9 | Mahnlauf ausführen | Überschrittene Zahlungsziele erzeugen die vorgesehene Mahnstufe; bezahlte Rechnungen werden nicht angemahnt |
Bestellung bis Zahlung (Purchase to Pay)
| Nr. | Testfall | Erwartetes Ergebnis |
|---|---|---|
| 10 | Bestellvorschlag in Bestellung überführen | Lieferant, Preis, Liefertermin und Bestellnummer werden übernommen |
| 11 | Wareneingang zur Bestellung buchen | Die Position gilt als geliefert, der Bestand steigt, die offene Bestellmenge sinkt |
| 12 | Teillieferung und Sperrlager abwickeln | Nur die geprüfte Menge wird freigegeben, der Rest bleibt gesperrt oder offen |
| 13 | Eingangsrechnung ohne Bestellbezug erfassen | Das System verlangt die vorgesehene Prüfung oder Freigabe und bucht erst danach |
| 14 | Dreifachabgleich Bestellung, Wareneingang, Rechnung | Abweichung innerhalb der festgelegten Toleranz wird gebucht, darüber hinaus blockiert der Vorgang |
| 15 | Eingangsrechnung als strukturierte Datei einlesen | Beträge, Steuerschlüssel und Lieferantennummer stimmen; die Datei bleibt auffindbar (nur für Formate, die Ihr System unterstützt) |
| 16 | Zahlungslauf ausführen | Fälligkeiten und Skonto sind berücksichtigt, bezahlte Posten sind ausgeglichen, der Vorschlag ist abgezeichnet |
Monatsabschluss
| Nr. | Testfall | Erwartetes Ergebnis |
|---|---|---|
| 17 | Wareneingang ohne Rechnung abschließen | Offene Wareneingänge erscheinen zum Stichtag in der vorgesehenen Abgrenzung |
| 18 | Rechnung ohne Wareneingang abschließen | Die Rechnung bleibt der Bestellung zugeordnet und wird als noch nicht geliefert geführt |
| 19 | Inventur erfassen und Differenz buchen | Zählmenge wird übernommen, die Differenz gebucht, der Bestandswert vor und nach der Buchung ist nachvollziehbar |
| 20 | Periodensperre setzen | Eine Buchung im gesperrten Vormonat wird abgewiesen, eine Buchung in der offenen Periode geht durch |
| 21 | Steuerauswertung für den Abrechnungszeitraum erzeugen | Summen und Steuerschlüssel stimmen mit den gebuchten Belegen überein (in Deutschland und Österreich Umsatzsteuer, in der Schweiz Mehrwertsteuer) |
| 22 | Export für die Buchhaltung erzeugen und rücklesen | Konten, Beträge und Steuerschlüssel kommen im Zielsystem unverändert an, etwa im Buchungsstapel-Export für die Buchhaltung in Deutschland |
Querschnitt
| Nr. | Testfall | Erwartetes Ergebnis |
|---|---|---|
| 23 | Offene Posten gegen das Saldenkonto abstimmen | Die Summe der offenen Posten je Debitor und Kreditor entspricht dem Saldenkonto der offenen Posten und Salden |
| 24 | Verkauf aus Kassensystem oder Shop übernehmen | Im ERP entstehen Beleg, Bestandsbuchung und Umsatz; eine Rückgabe bucht dieselben Werte zurück (nur für Schnittstellen, die Sie einsetzen) |
| 25 | Rollen und Berechtigungen prüfen | Eine Rolle ohne Recht kann im gesperrten Zeitraum nicht buchen; jede Freigabe und Änderung ist im Protokoll einer Person zuordenbar |
Die Datenübernahme selbst prüfen Sie mit den beiden Probeläufen aus der Probemigration; Bestand und Zählung für Fall 19 bereiten Sie mit dem Lagerbestand zum Stichtag vor.
So prüfen Sie das Ergebnis
- Jeder Fall trägt eine Nummer, den Bezug zum Prozessschritt und ein erwartetes Ergebnis, das vor dem Lauf feststand.
- Alle 25 Standardfälle sind entschieden: ausgeführt, angepasst oder mit Begründung gestrichen.
- Kein Schritt Ihres Testumfangs steht ohne Fall; je Schritt liegen mindestens drei vor: Normalfall, Grenzfall an der Grenze und Fehlerfall mit ungültigen Werten.
- Die Spur vom Prozessschritt zum Fall ist lückenlos und erleichtert die Nachprüfung (Lehrplan, Abschnitt 1.4.4).
- Jeder fehlgeschlagene Fall hat eine Fehlernummer, eine zuständige Person und einen Termin.
- Zu jedem bestandenen Fall liegen Nachweis, Version und Datum vor.
- Die Austrittskriterien des Laufs sind erreicht; die Abnahme entscheidet danach die Geschäftsführung.
Wenn etwas nicht klappt
| Symptom | Mögliche Ursache | Vorgehen |
|---|---|---|
| Alle Fälle bestehen im ersten Lauf | nur Normalfälle, keine Grenz- und Fehlerfälle | Werte an der Grenze und daneben ergänzen, Entscheidungstabelle aufstellen |
| Der Testtag geht mit Suchen verloren | Testdaten je Fall nicht vorbereitet | Datenliste je Fall anlegen und im Testsystem vorab prüfen |
| Ein Fehler lässt sich nicht nachstellen | Schritte und Werte nicht mitgeschrieben | Schritte, Werte und Version im Fehlerbericht nachtragen, Fall wiederholen |
| Bestandene Fälle sind nicht belegbar | Nachweis nicht festgehalten | Belegnummer, Auswertung, Version und Datum je Fall nachtragen |
| Der Anbieter meldet „getestet“ | der Betrieb hat die Fälle nicht selbst ausgeführt | Fälle im eigenen Testsystem ausführen und selbst protokollieren |
| Nach einer Anpassung bricht ein alter Fall | Änderung ohne Wiederholung der Nachbarfälle | Fälle der betroffenen Abläufe erneut ausführen und im Anpassungsverzeichnis eintragen |
| Zwei Personen melden denselben Fehler | keine gemeinsame Fehlerliste | eine Liste mit laufender Nummer führen, Dubletten zusammenführen |
Was Normen und Lehrplan dazu sagen
ISO/IEC/IEEE 29119-2:2021 beschreibt Testprozesse, mit denen eine Organisation Tests steuert, verwaltet und durchführt; Teil 3:2021 desselben Standards beschreibt Vorlagen für die Testdokumentation (Angaben der IEC-Verlagsseite, Ausgabe 2.0, 28. Oktober 2021, geöffnet am 14. Oktober 2026). Beide Teile sind kostenpflichtig und nicht frei einsehbar; Schrittfolge, Vorlage und die 25 Fälle sind eigene Festlegungen. Eine Norm bindet nicht durch Gesetz: verbindlich wird sie, wenn ein Vertrag, eine Ausschreibung oder ein Qualitätssicherungssystem sie in Bezug nimmt.
Der Lehrplan des ISTQB Certified Tester Foundation Level liegt als Fassung v4.0.1 vom 15. September 2024 frei zum Herunterladen vor (Verbandsseite, geöffnet am 14. Oktober 2026). Aus ihm stammen die Angaben zu den Testaktivitäten (1.4.1), zur Nachverfolgbarkeit (1.4.4), zu den Testverfahren (4.2), zum Inhalt eines Testplans (5.1.1), zu Ein- und Austrittskriterien (5.1.3), zur Priorisierung (5.1.5) und zum Fehlerbericht (5.5). Er ist kein Standard und keine Rechtsnorm und bindet nur, wenn Sie ihn vereinbaren.
Wann Sie Hilfe holen sollten
Ziehen Sie Ihre Steuerberatung hinzu, wenn Testfälle die Buchhaltung betreffen: Kontenrahmen, Steuerschlüssel, Auswertungen und Exporte. Klären Sie mit ihr auch, welche Projektunterlagen Sie später für eine Nachprüfung vorhalten wollen. Fragen zu Personendaten in Testdaten gehören zur Datenschutzberatung. Den Anbieter brauchen Sie, wenn ein Fall nur mit einer Programmänderung bestehen könnte: Die Änderung wird als Anpassung beauftragt, dokumentiert und danach erneut getestet. Reicht das Testfenster nicht, kürzen Sie den Umfang sichtbar und verschieben einzelne Fälle mit Datum, statt die Fälle in der Sitzung durchzuwinken.