Update im Testsystem prüfen: Testfälle und Abnahme

Ein Update tauscht mehr als die Funktionen, die in den Releasenotes stehen. Weil eine Änderung auch an Stellen wirken kann, die niemand angefasst hat, gehört sie zuerst in eine getrennte Umgebung. Der Ablauf unten führt vom Änderungsumfang über die vier Kernabläufe zur unterschriebenen Freigabe. Die Fallliste und das Abnahmeblatt sind Vorlagen; Ihre Nummernkreise, Konten und Erwartungswerte tragen Sie aus dem eigenen System ein.

Was Sie vorab brauchen

• eine Testumgebung, die vom Produktivsystem getrennt betrieben wird, mit demselben Release-Stand, denselben Einstellungen, Anpassungen, Vorlagen und Auswertungen wie die Produktion
• Testdaten für die vier Abläufe: Kunden, Lieferanten, Artikel, ein offenes Buchungsjahr und mindestens ein offener Posten auf der Kunden- und der Lieferantenseite
• Ihr Verzeichnis der Anpassungen mit dem Prüffall je Eintrag, geführt wie unter Anpassungen updatefähig dokumentieren
• die Fallliste der vier Kernabläufe aus diesem Artikel, ergänzt um Ihre Nummernkreise, Konten und Toleranzen
• das Abnahmeblatt (unten) einmal je Update
• zwei Personen: die Testenden führen aus, die fachlich zuständige Stelle entscheidet und zeichnet ab
• eine geprüfte Sicherung und eine Rückfall-Lösung mit gemessenem Zeitbedarf, geprüft wie beim Wiederherstellungstest
• ein Einspielfenster in der Produktion und ein Ansprechpartner beim Anbieter

Schritt für Schritt: vom Update im Testsystem zur Freigabe

Schritt 1: Änderungsumfang und Risiko bestimmen

Klären Sie, was das Update ändert und was es berühren kann. Der Lehrplan nennt für den Wartungstest drei Größen, nach denen sich der Prüfumfang richtet: das Risiko der Änderung, die Größe des bestehenden Systems und die Größe der Änderung (Abschnitt 2.3). Ein Sicherheitspatch mit kleinen Änderungen wird deshalb kürzer geprüft als ein Versionswechsel, aber nicht gar nicht.

Gehen Sie Ihr Anpassungsverzeichnis durch und markieren Sie jeden Eintrag, dessen Funktion oder Datenstruktur das Update betreffen kann; das ist die Auswirkungsanalyse, die der Lehrplan vor dem Regressionstest empfiehlt (Abschnitt 2.2.3). Ergebnis: je Kernablauf steht die geplante Testtiefe, und jeder ausgeschlossene Ablauf trägt eine Begründung.

Schritt 2: Das Testsystem auf den Produktivstand bringen

Das Update soll auf denselben Ausgangsstand treffen wie später in der Produktion. Bringen Sie Konfiguration, Anpassungen, Vorlagen, Nummernkreise und Stammdaten auf den Stand des Produktivsystems und schreiben Sie die Unterschiede auf, die Sie bewusst stehen lassen. Ersetzen Sie Adressen von Mail, Bank und Shop durch Testziele, damit aus dem Testsystem keine Nachricht und kein Zahlungsauftrag nach außen geht.

Als Testdaten dienen ein eigener Bestand oder ein geschützter Auszug; zu den Einzelheiten siehe die FAQ unten. Ergebnis: eine kurze Liste, welche Unterschiede zwischen Test- und Produktivsystem bestehen, und eine Umgebung, die niemand im Tagesgeschäft benutzt.

Schritt 3: Sicherung und Rückfall-Lösung bereitstellen

Halten Sie beides bereit, bevor das erste Paket aufgespielt wird: eine Sicherung des Produktivsystems mit geprüftem Restore und eine Rückfall-Lösung für das Testsystem selbst. Wer den IT-Grundschutz anwendet, muss beim Installieren von Patches und beim Durchführen von Änderungen Rückfall-Lösungen vorhalten (OPS.1.1.3.A1). Schreiben Sie auf, in welcher Reihenfolge ein Rückfall abläuft und wie lange er dauert.

Ergebnis: Der Rückfallweg steht mit Schritten und Zeitbedarf, und die Sicherung ist als lesbar und zurückspielbar belegt.

Schritt 4: Das Update einspielen und einen Rauchtest fahren

Spielen Sie das Paket nach der Installationsanleitung des Anbieters ein, nicht nach einer Kurzanleitung aus zweiter Hand. Notieren Sie Releasestand, Build und Datum. Wer den IT-Grundschutz anwendet, soll dabei die Installation und, falls vorhanden, die Installations- und Konfigurationsdokumentation überprüfen (OPS.1.1.6.A15).

Danach ein Rauchtest mit wenigen Handgriffen: Anmeldung, ein Vorgang, ein Druck. Er zeigt, dass das System überhaupt läuft; er ersetzt keinen Fall aus der Liste. Ergebnis: Version und Rauchtest stehen im Protokoll.

Schritt 5: Die Kernabläufe gegen die Fallliste prüfen

Arbeiten Sie die Fälle der Reihe nach ab und tragen Sie je Fall das Ist-Ergebnis mit Datum, Version und Nachweis ein. Als Nachweis dient die Vorgangsnummer, die Auswertung oder der Ausdruck. Die Testfälle müssen so ausgewählt sein, dass sie möglichst repräsentativ alle Funktionen abdecken; zusätzlich sollen Negativfälle ein unerwünschtes Verhalten aufdecken (OPS.1.1.6.A1). Verzichten Sie nicht auf das Nachstellen des Fehlers, den der Anbieter mit dem Update beheben wollte: Erst der bestandene Fall belegt die Behebung.

Testen Sie nicht im laufenden Produktivsystem. Die funktionalen Tests müssen so durchgeführt werden, dass sie den Produktivbetrieb nicht beeinflussen (OPS.1.1.6.A2). Ergebnis: jeder Fall trägt einen Status — bestanden, fehlgeschlagen, blockiert oder nicht ausgeführt.

Schritt 6: Fehler aufnehmen, beheben und nachtesten

Jeder fehlgeschlagene Fall wird zu einem Eintrag mit Nummer, erwartetem und tatsächlichem Ergebnis, Zuständigem und Termin. Nach einer Behebung laufen zwei Prüfungen: der ursprünglich fehlgeschlagene Fall, um die Behebung zu bestätigen, und die benachbarten Fälle, um Nebenwirkungen auszuschließen (Lehrplan, Abschnitt 2.2.3).

Wer den IT-Grundschutz anwendet, soll Regressionstests vollständig durchführen und jeden ausgelassenen Fall mit Begründung dokumentieren (OPS.1.1.6.A12; A12 ist eine Standard-Anforderung und damit eine Empfehlung). Dieser Artikel geht darüber hinaus: kein Fehler verschwindet ohne Abschluss, und die erneut geprüften Bereiche sind im Protokoll benannt.

Schritt 7: Auswerten und die Freigabe erklären

Werten Sie die Ergebnisse aus und dokumentieren Sie diese Auswertung; ein Soll-Ist-Vergleich mit den vorher festgelegten Erwartungen soll dazugehören (OPS.1.1.6.A3). Danach entscheidet die fachlich zuständige Stelle, ob das Update produktiv gehen darf, und dokumentiert die Freigabe als Erklärung (OPS.1.1.6.A4). Sie prüft dabei, ob gemäß den Anforderungen getestet wurde und ob die Ergebnisse den Erwartungen entsprechen.

Legen Sie vorab fest, was bei einer Ablehnung geschieht; das empfiehlt ein Abnahmeplan, der die Testarten, Testfälle, erwarteten Ergebnisse und die Freigabekriterien festhält (OPS.1.1.6.A10, Standard-Anforderung). Als Entscheidungsregel dieses Artikels gilt: blockiert ein Fehler einen Kernablauf, wird nicht freigegeben; nicht blockierende Fehler gehen nur mit Zuständigem und Termin als Auflage mit. Ergebnis: ein unterschriebenes Abnahmeblatt, notfalls mit Auflagen.

Schritt 8: Produktiv einspielen und nachkontrollieren

Spielen Sie im geplanten Fenster denselben Stand ein, den Sie getestet haben, und folgen Sie dabei der Reihenfolge, die sich im Test bewährt hat. Unmittelbar danach ein Rauchtest in der Produktion und die kritischen ersten Vorgänge: eine Rechnung, ein Wareneingang, ein Zahlungslauf im Vorschau-Modus. Weicht das Ergebnis vom Test ab, greift der Rückfallweg aus Schritt 3. Ergebnis: Einspielung, Rauchtest und Abweichungen stehen mit Uhrzeit im Protokoll.

Die Testfälle für die vier Kernabläufe

Die folgende Liste ist eine Auswahl dieses Artikels, keine Normvorgabe. Sie deckt die vier Abläufe ab, die dieses Blatt abzeichnet: Auftrag bis Rechnung, Wareneingang, Zahlungslauf und Monatsabschluss. Erwartete Ergebnisse mit Zahlen setzen Sie aus Ihrem eigenen System ein; die Fälle sind fortlaufend nummeriert und werden je Lauf vollständig entschieden.

Nr.	Kernablauf	Testfall	Erwartetes Ergebnis
1	Auftrag bis Rechnung	Auftrag mit Rabatt und Zahlungsziel in eine Rechnung überführen	Positionssummen, Rabatt und Steuerschlüssel wie im Auftrag; Rechnungsnummer im gewohnten Nummernkreis
2	Auftrag bis Rechnung	Sammelrechnung aus mehreren Lieferscheinen erzeugen	Alle Lieferscheine enthalten, Rechnungssumme und offener Posten stimmen
3	Auftrag bis Rechnung	Rechnung stornieren oder gutschreiben	Gegenbeleg mit eigener Nummer; der offene Posten ist ausgeglichen
4	Auftrag bis Rechnung	Mahnlauf und Liste der offenen Posten ausführen	Fälligkeiten und Mahnstufen unverändert; bezahlte Posten werden nicht angemahnt
5	Wareneingang	Bestellung anlegen und vollständig liefern	Bestand und Wert steigen, offene Bestellmenge sinkt auf null
6	Wareneingang	Teillieferung zur Bestellung buchen	Restmenge bleibt offen, der Status steht auf teilgeliefert
7	Wareneingang	Wareneingang über der Toleranz erfassen	Über der festgelegten Toleranz wird der Vorgang gesperrt und nicht gebucht
8	Wareneingang	Rücksendung an den Lieferanten buchen	Bestand sinkt um die zurückgesendete Menge (Buchungsannahme dieses Artikels: Lagerabgang aus der Rücksendung)
9	Wareneingang	Lieferantengutschrift zur Rücksendung buchen	Kreditorenposten sinkt um den Wert der Gutschrift; Buchungsannahme vorab festlegen (Gutschriftsbeleg oder Verrechnung mit einer offenen Rechnung)
10	Zahlungslauf	Zahlungsvorschlag nach Fälligkeit und Skontofrist erzeugen	Fristen und Abzüge je Position wie vor dem Update; Summe und Positionszahl stehen im Vorschlag
11	Zahlungslauf	Zahlungsdatei aus dem freigegebenen Vorschlag erzeugen	Kontrollsumme und Anzahl stimmen; die Prüfung der Bank nimmt die Datei an (Testkonto)
12	Zahlungslauf	Lauf über der festgelegten Betragsgrenze freigeben	Ohne zweite Freigabe bleibt der Lauf gesperrt
13	Zahlungslauf	Zahlungen buchen und Posten ausgleichen	Rechnungen ausgeglichen, Bankkonto belastet, keine offene Differenz
14	Monatsabschluss	Buchung in der gesperrten Periode versuchen	Das System weist die Buchung ab; in der offenen Periode geht sie durch
15	Monatsabschluss	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)
16	Monatsabschluss	Export an Buchhaltung oder Steuerberatung erstellen und zurücklesen	Konten, Beträge und Steuerschlüssel kommen im Zielsystem unverändert an
17	Monatsabschluss	Offene Posten gegen das Saldenkonto abstimmen	Differenz null je Debitor und Kreditor
18	Querschnitt	Anpassung, Bericht und Druckvorlage aufrufen	Eigene Anpassungen laufen ohne Fehlermeldung; Formular und Auswertung drucken vollständig
19	Querschnitt	Benutzerrolle ohne Buchungsrecht anmelden	Die Rolle kann im gesperrten Zeitraum nicht buchen; jede Änderung ist einer Person zuordenbar
20	Querschnitt	Schnittstelle oder Job starten (Import, Shop, Kasse)	Jeder Datensatz kommt einmal an, ohne Doppelbuchung

Die Fälle 5 und 7 bauen auf dem Dreifachabgleich auf, der unter Bestellung, Wareneingang und Rechnung prüfen beschrieben ist. Den Zahlungslauf selbst führt der Ablauf unter Zahlungslauf per SEPA aus; die Fälle 14 bis 17 hängen am Monatsabschluss. Anbindungen prüfen Sie zusätzlich nach der Matrix aus dem Schnittstellentest.

Das Abnahmeblatt

Das Blatt ist die Vorlage dieses Artikels und wird je Update einmal ausgefüllt. Es belegt, was geprüft wurde und wer die Freigabe trägt; es ersetzt nicht die Projektabnahme nach der Einführung, für die der Abnahmetest im ERP-Projekt gilt.

Feld	Eintrag
Update und Version	Bezeichnung des Updates, Releasestand, Build, Datum der Bereitstellung
Testumgebung	Name des Testsystems, Datenstand, Stand der Anpassungen
Prüfzeitraum	von und bis, beteiligte Personen
Fallliste	Gesamtzahl der Fälle, davon bestanden, fehlgeschlagen, blockiert, nicht ausgeführt
Ausgelassene Fälle	Nummer und Begründung
Offene Fehler	Nummer, Beschreibung, blockierend ja oder nein, Zuständiger, Termin
Soll-Ist-Vergleich	Verweis auf die Ergebnisliste mit Datum
Rückfall-Lösung	Sicherung, geprüfter Restore, Zeitbedarf, Stichtag
Einspielung	geplantes Fenster in der Produktion, Ansprechpartner, Reihenfolge
Entscheidung	freigegeben, freigegeben mit Auflagen oder nicht freigegeben, mit Begründung
Auflagen	Punkt, Zuständiger, Termin
Abzeichnung	fachlich zuständige Stelle mit Name und Datum, zweite Unterschrift des IT-Betriebs

So prüfen Sie das Ergebnis

1. Jeder Fall der Liste trägt einen Status; „nicht ausgeführt“ hat eine Begründung und einen neuen Termin.
2. Der Soll-Ist-Vergleich liegt unterschrieben vor, und die geprüfte Version ist im Blatt benannt.
3. Jeder offene Fehler hat eine Nummer, eine Einstufung und einen Zuständigen mit Termin.
4. Die Rückfall-Lösung ist vor dem Einspielen geprüft, nicht erst danach geplant.
5. Die produktiv eingespielte Version stimmt mit der getesteten überein.
6. Nach dem Einspielen sind Rauchtest und erste Vorgänge im Produktivsystem protokolliert.

Wenn etwas nicht klappt

Symptom	Mögliche Ursache	Vorgehen
Die Fälle bestehen im ersten Lauf alle	nur Normalfälle, keine Grenz- und Fehlerfälle	Werte an der Grenze und daneben ergänzen, Negativfälle nachziehen
Ein Fehler lässt sich nicht nachstellen	Schritte, Werte oder Version fehlen im Protokoll	Schritte und Werte nachtragen, Fall auf demselben Stand wiederholen
Der Testtag geht mit Suchen verloren	Testdaten je Fall fehlen im Testsystem	Daten je Fall vorab anlegen und vor dem Lauf prüfen
Ein Fehler tritt nur im Testsystem auf	Test- und Produktivsystem unterscheiden sich	Unterschiede aus Schritt 2 durchgehen und die Umgebung angleichen
Nach einer Behebung bricht ein alter Fall	der Nachbarfall wurde nicht wiederholt	betroffene Abläufe erneut prüfen, Ergebnis im Blatt nachtragen
Die Freigabe wird mündlich erteilt	keine unterschriebene Erklärung	Freigabe schriftlich nachholen, sonst bleibt der Vorgang offen

Was der Lehrplan und der IT-Grundschutz dazu sagen

Der Lehrplan ISTQB Certified Tester Foundation Level v4.0.1 liegt frei zum Herunterladen vor (Fassung vom 15. September 2024, Verbandsseite). Aus ihm stammen die Unterscheidung von Bestätigungs- und Regressionstest samt Auswirkungsanalyse (Abschnitt 2.2.3), die drei Größen für den Umfang des Wartungstests (Abschnitt 2.3), die Ein- und Austrittskriterien (Abschnitt 5.1.3) und der Inhalt eines Abschlussberichts (Abschnitt 5.3.2, mit Verweis auf ISO/IEC/IEEE 29119-3). Der Lehrplan ist ein Zertifizierungslehrplan; verbindlich wird er, wenn Sie ihn oder eine Zertifizierung vereinbaren.

Die konkreten Anforderungen stammen aus dem IT-Grundschutz-Kompendium des BSI, Edition 2023, Baustein OPS.1.1.6 Software-Tests und -Freigaben. Als Basis-Anforderungen MÜSSEN vorrangig erfüllt werden: Planung der Tests und repräsentative Fallauswahl (A1, Negativ-Tests darin nur SOLLTE), funktionale Tests ohne Einfluss auf den Produktivbetrieb (A2), Auswertung der Ergebnisse mit dokumentierter Auswertung und einem Soll-Ist-Vergleich (A3, der Soll-Ist-Vergleich darin nur SOLLTE), die schriftliche Freigabeerklärung durch die fachlich zuständige Stelle (A4) und der Schutz der Testdaten (A11). Als Standard-Anforderungen SOLLTEN grundsätzlich erfüllt werden: vollständige Regressionstests mit begründet dokumentierten Auslassungen (A12), die getrennte Testumgebung (A13), ein Abnahmeplan mit Freigabekriterien und Vorgehen bei Ablehnung (A10) und die Prüfung von Installation und Dokumentation (A15). Aus dem Baustein OPS.1.1.3 Patch- und Änderungsmanagement kommt die Rückfall-Lösung (A1, Basis-Anforderung). Diese Anforderungen gehören zur Methodik des BSI; sie binden, soweit eine Regelung, eine Prüfung oder ein Vertrag den IT-Grundschutz in Bezug nimmt.

Wann Sie Hilfe holen sollten

• Anbieter: bei jedem Fehler, der nach einem Defekt aussieht, und wenn Angaben zu Version, Build oder Voraussetzungen des Pakets fehlen.
• Steuerberatung: bei den Fällen des Monatsabschlusses, also bei Kontenrahmen, Steuerschlüsseln, Auswertungen und Exporten.
• Datenschutzberatung: bevor Produktivdaten in das Testsystem gelangen, und bei der Frage, wie ein Datenauszug geschützt wird.
• Geschäftsführung: bei der Entscheidung über Freigabe, Auflagen oder Verschieben, wenn ein Kernablauf betroffen ist.
• IT-Betrieb: wenn sich Test- und Produktivsystem nicht angleichen lassen, weil Schnittstellen oder Lizenzen fehlen.