S/4HANA-Teststrategie: Zyklen, Kriterien und Rollen

Eine S/4HANA-Teststrategie entscheidet, welche Testzyklen Sie durchführen, in welcher Reihenfolge, wer jeden verantwortet und welche Nachweise den Übergang vom einen zum nächsten erlauben. In meinen Programmen umfasst sie den Integrationstest (SIT) in Runden, den Benutzerakzeptanztest (UAT) in Runden und den Regressionstest, jeweils mit schriftlichen Eingangs- und Ausgangskriterien und einer namentlich benannten Freigabe.

Tests beanspruchen in den S/4HANA-Programmen, die ich plane, rund 35 Prozent des Programmaufwands. Die Strategie verdient also genauso viel Sorgfalt wie der Build-Plan.

Die Testarten selbst behandle ich in meinem Leitfaden SAP-Tests erklärt. Dieser Artikel ist die Strategieebene: Zyklen, Kriterien, Rollen und die Gliederung des Dokuments.

SAP Activate legt den Großteil der Tests in Realize. Das Material von SAP zur Teststrategie für S/4HANA Cloud Private Edition behandelt Unit- und String-Tests als informell. Vollständige Geschäftsprozess-, Integrations-, Datenmigrations- und Benutzerakzeptanztests sind formal und müssen dokumentiert werden.

Diese Abfolge plane ich in einem S/4HANA-Programm:

S/4HANA-Testzyklen

1. 01

   Unit und String

   Berater testen jede konfigurierte Funktion und kurze Ketten, während sie bauen.

2. 02

   SIT-Runden

   Vollständige Prozessketten über Module, Schnittstellen und migrierte Daten.

3. 03

   UAT-Runden

   Fachanwender belegen Runde für Runde, dass das System ihre Prozesse abbildet.

4. 04

   Regression

   Erneut testen, was bereits bestanden hat, nach Korrekturen, Transporten und Releases.

5. 05

   Probekonvertierungen und Generalprobe

   Den Cutover so durchspielen, wie er in der echten Nacht läuft, gegen die Checkliste.

6. 06

   Go-live

   Nur live gehen, wenn die vereinbarte Cutover-Checkliste vollständig ist.

Unit- und String-Test

Berater und Entwickler testen jedes Konfigurationselement und jede Entwicklung, während sie es bauen. String-Tests verketten einige Schritte, etwa einen Kundenauftrag bis zur Lieferung.

Nach SAP-Lesart informell, aber nicht optional.

Integrationstest in Runden

Der SIT testet vollständige Geschäftsprozesse über Module, Schnittstellen und konvertierte oder geladene Daten hinweg. Ich plane ihn in Runden statt als ein einziges Ereignis, damit Fehler, die nach einer Runde behoben wurden, in der nächsten erneut getestet werden.

Eine feste Zahl an SIT-Runden habe ich nicht. Sie hängt von der Zahl der Prozesse, Schnittstellen und Gesellschaften im Scope ab, und die Strategie sollte sagen, wie viele Runden es sind und warum.

Benutzerakzeptanztest in Runden

Im UAT bestätigt der Fachbereich mit eigenen Leuten und realistischen Daten, dass das System seine Prozesse abbildet. Wie den SIT plane ich ihn in Runden, damit Korrekturen aus einer Runde in der nächsten erneut getestet werden.

Der UAT braucht mindestens 6 bis 8 Wochen. Fachliche Tester machen das neben ihrer normalen Arbeit und brauchen Zeit für mehr als eine Runde. Mein Leitfaden zum SAP-Benutzerakzeptanztest behandelt Testskripte, Runden und Freigabe im Detail.

Regressionstest

Jede Korrektur, jeder Transport und jedes Release kann etwas brechen, das bereits bestanden hat. Der Regressionstest wiederholt nach jeder Änderung die Prozesse, auf die es ankommt, während des Programms und nach dem Go-live.

Das SAP-Material verortet die Regression vor allem in Run, nach Release-Upgrades, aber ein Programm braucht sie schon früher. Ansatz, Auswirkungsanalyse und Umgebungsaufbau stehen in meinem Leitfaden zum SAP-Regressionstest.

Probekonvertierungen und Cutover-Generalprobe

Bei einer Brownfield-Konvertierung plane ich drei Probekonvertierungen vor dem Cutover. Jede testet die Konvertierung selbst, die Laufzeiten und die Abstimmung, nicht nur die Prozesse.

Die letzte Generalprobe sollte laufen wie die echte Nacht: gleiche Abfolge, gleiche Leute, gleiche Checkliste. Mein S/4HANA-Migrationszeitplan und Projektplan zeigt, wo diese Läufe im Plan liegen.

Die wichtigste Entscheidung zur Verantwortung: Der Fachbereich verantwortet den Benutzerakzeptanztest. Nicht der Systemintegrator und nicht die IT.

Ein Integrator kann Skripte vorbereiten und Fehler beheben. Nur die Leute, die Ihren Finanzabschluss, Ihr Order-to-Cash oder Ihr Werk betreiben, können bestätigen, dass diese Prozesse funktionieren.

Die Empfehlungen von SAP zeigen in dieselbe Richtung. Konfigurationsexperten des Partners erstellen die Testfälle, und Fachexperten des Kunden aus den Geschäftsbereichen führen den UAT durch und dokumentieren die Ergebnisse.

So würde ich die Verantwortung über die Zyklen aufteilen:

Zyklus	Verantwortlich	Führt aus	Gibt frei
Unit und String	Leiter des Build-Teams	Berater und Entwickler	Funktionale und technische Leads
SIT-Runden	Testmanager	Berater, in späteren Runden mit Key Usern	Testmanager und Prozessverantwortliche
UAT-Runden	Der Fachbereich, über namentlich benannte Prozessverantwortliche	Key User und fachliche Tester	Prozessverantwortliche, dann der Sponsor
Regression	Testmanager	Testteam, automatisiert, wo das Volumen es rechtfertigt	Testmanager und Change Board
Probekonvertierungen und Generalprobe	Cutover-Leiter	Technik-, Daten- und Funktionsteams	Cutover-Leiter, Datenverantwortlicher und Sponsor

Schreiben Sie Namen in die Strategie, nicht Rollen. „Prozessverantwortlicher Finanzwesen“ ist eine Rolle; eine namentlich benannte Person, die zugesagt hat zu unterschreiben, ist eine Verantwortliche.

Eingangskriterien verhindern, dass ein Zyklus beginnt, bevor er gelingen kann. Ausgangskriterien verhindern, dass er endet, nur weil der Kalender es sagt.

Schreiben Sie beide, bevor Realize beginnt, solange niemand unter Termindruck steht. Mein Leitfaden zu SAP Quality Gates erklärt, wie diese Kriterien zu formalen Gates werden, mit einem Verantwortlichen, der „nicht bereit“ sagen kann.

Die Tabelle unten ist eine Orientierung zum Anpassen, kein Standard zum Abschreiben. Legen Sie Prozentsätze und Fehlergrenzen mit Ihrem Sponsor fest und halten Sie sie in der Strategie fest:

Zyklus	Eingangskriterien	Ausgangskriterien
Unit und String	Design freigegeben; Konfiguration und Entwicklung für die getesteten Elemente abgeschlossen	Alle Elemente getestet und dokumentiert; Fehler behoben oder für den SIT erfasst
SIT-Runde	Unit-Tests für die Prozesse im Scope abgeschlossen; Testumgebung aufgebaut und Schnittstellen angebunden; Testdaten geladen; Skripte geprüft	Vereinbarter Anteil der Skripte ausgeführt und bestanden; keine offenen kritischen Fehler; offene niedrigere Fehler haben jeweils einen Verantwortlichen und einen Korrekturtermin
UAT-Runde	SIT-Ausgangskriterien erfüllt; fachliche Tester benannt und vom Tagesgeschäft freigestellt; Skripte von den Prozessverantwortlichen geprüft; Schulung auf dem Testsystem erfolgt	Jeder Prozess im Scope von Fachanwendern ausgeführt; keine offenen kritischen Fehler; Prozessverantwortliche haben ihre Prozesse unterschrieben
Regression	Eine Änderung, ein Korrekturpaket oder ein Release bereit zum Transport; Regressionspaket für die betroffenen Prozesse vereinbart	Regressionspaket bestanden; jeder Fehler behoben und erneut getestet, bevor die Änderung weitergeht
Probekonvertierung oder Generalprobe	Produktionskopie verfügbar; Cutover-Checkliste und Runbook im Entwurf; Abstimmregeln vereinbart	Konvertierung oder Ladung im geplanten Zeitfenster abgeschlossen; Abstimmung vom Datenverantwortlichen unterschrieben; Checkliste um Erkenntnisse ergänzt
Go-live	Alle vorherigen Ausgangskriterien erfüllt; Cutover-Checkliste vorab vereinbart	Jeder Punkt der Checkliste erledigt und unterschrieben; Go/No-Go vom Sponsor dokumentiert

Zwei Regeln lassen die Tabelle funktionieren. Jedes Kriterium liefert eine Ja-oder-Nein-Antwort, und jeder Ausgang hat einen namentlich benannten Unterzeichner.

Verfehlt ein Zyklus seine Ausgangskriterien und will der Fachbereich trotzdem weitermachen, machen Sie daraus eine schriftliche Entscheidung. Nennen Sie die Person, die das Risiko akzeptiert hat, und die Fehler, die mitgenommen werden.

Der Testmanager schreibt es in Prepare oder frühem Explore, und der Sponsor genehmigt es. Halten Sie es so kurz, dass Prozessverantwortliche es lesen.

Diese Abschnitte erwarte ich:

1. Scope und Ziele. Welche Prozesse, Gesellschaften, Schnittstellen und Berichte getestet werden und welche ausdrücklich nicht.
2. Testarten und Zyklen. Unit, String, SIT-Runden, UAT-Runden, Regression, Performance, Tests der Datenmigration und Probekonvertierungen, mit der Zahl der Runden und der Begründung.
3. Zeitplan und Aufwand. Termine für jeden Zyklus im SAP-Activate-Plan, mit mindestens 6 bis 8 Wochen für den UAT, und der Aufwand budgetiert gegen den Testanteil von rund 35 Prozent.
4. Rollen und Verantwortung. Die Verantwortungstabelle oben, mit Namen.
5. Eingangs- und Ausgangskriterien. Ein Satz pro Zyklus, mit dem Unterzeichner für jeden.
6. Umgebungen. Welche Systeme für welchen Zyklus genutzt werden, wie sie aufgefrischt werden und wie Projektänderungen von Live-Supportänderungen getrennt bleiben.
7. Testdaten. Woher die Daten kommen, wie sie maskiert und wie sie zwischen den Runden aufgefrischt werden. Mein Leitfaden zum SAP-Testdatenmanagement behandelt das ausführlich.
8. Fehlermanagement. Definitionen der Schweregrade, Triage-Rhythmus, wer über die Priorität entscheidet und die Zielzeit für die Korrektur je Schweregrad.
9. Tools. Wo Testfälle, Ergebnisse, Fehler und Freigaben liegen, mit einem einzigen führenden System.
10. Automatisierungsansatz. Welche Tests automatisiert werden, welche manuell bleiben und warum.
11. Reporting. Was der wöchentliche Testbericht zeigt und wer ihn erhält.
12. Cutover- und Go-live-Kriterien. Die Cutover-Checkliste, die Generalproben, die sie belegen, und wer die Go/No-Go-Entscheidung trifft.
13. Risiken und Annahmen. Verfügbarkeit der Tester, Umgebungstermine, Datenbereitschaft und Abhängigkeiten von Dritten.

Bei den Tools ist SAP Cloud ALM der Standard für neue Programme. SAP stellt klar, dass es keine separate Lizenz für SAP Cloud ALM gibt: Es ist in Enterprise Support enthalten, und seine Testmanagement-Apps enthalten die formalen Testfälle, Läufe und Ergebnisse.

SAP Solution Manager 7.2 ist in vielen Programmen noch im Einsatz, aber seine Mainstream-Wartung endet Ende 2027. Für die Automatisierung verkauft SAP SAP Test Automation by Tricentis, das mit Cloud ALM zusammenarbeitet; mein Vergleich der SAP-Testtools behandelt die breitere Auswahl.

Der häufigste Testfehler, den ich sehe, ist zu wenig Testen in UAT und SIT.

Ein typischer Mechanismus: Der Build verspätet sich, der Go-live-Termin bleibt fest, und die Wochen werden aus den Testzyklen genommen, weil sie am Ende des Plans liegen.

Diese Muster führen dazu, und so gehen Sie mit jedem um:

1. Der SIT beginnt, bevor die Unit-Tests fertig sind. Die erste SIT-Runde wird zur Unit-Test-Runde. Halten Sie die Eingangskriterien ein.
2. Der UAT ist für zwei oder drei Wochen geplant. In dieser Zeit können Fachanwender neben dem Tagesgeschäft nicht sauber testen. Planen Sie mindestens 6 bis 8 Wochen und stellen Sie die Tester frei.
3. Der Integrator führt den UAT für den Fachbereich durch. Die Skripte bestehen, und der Fachbereich findet die Lücken nach dem Go-live. Lassen Sie die Verantwortung für den UAT bei den Prozessverantwortlichen.
4. Das Testen ist als kleine Budgetposition eingeplant. Bei rund 35 Prozent des Aufwands wird ein Testbudget, das nur einen Bruchteil davon ansetzt, als Erstes gekürzt.
5. Ausgangskriterien werden während des Zyklus geschrieben. Am Ende passen sie zu dem, was das Team gerade erreicht hat. Schreiben Sie sie vor Realize.
6. Über den Go-live wird nach Gefühl entschieden, nicht nach Checkliste. Niemand kann zeigen, was vereinbart war, also kann niemand sagen, was fehlt.

Auf diesem letzten Punkt bestehe ich. Mein Go-live-Kriterium ist eine ausführliche Cutover-Checkliste, vorab vereinbart mit Fachbereich, IT und Integrator.

Sie umfasst technische Schritte, Datenladungen, Abstimmungen, fachliche Validierungen, Umschaltungen von Schnittstellen, Benutzerzugänge und Go/No-Go-Punkte. Ist ein Punkt nicht erledigt und unterschrieben, ist das Programm nicht bereit, egal welches Datum im Kalender steht.

Bevor Realize beginnt, fordern Sie von Ihrem Testmanager das Teststrategie-Dokument an und prüfen Sie es gegen die Gliederung oben. Hat es keinen namentlich benannten UAT-Verantwortlichen, gibt es dem UAT weniger als 6 bis 8 Wochen oder fehlen Eingangs- und Ausgangskriterien pro Zyklus, beheben Sie das zuerst.

Wenn Sie eine unabhängige Prüfung einer Teststrategie oder einer Go-live-Checkliste möchten: Dabei unterstütze ich Organisationen. Sie können mich hier kontaktieren.

Was ist eine S/4HANA-Teststrategie?

Der Plan, der entscheidet, welche Testzyklen laufen, in welcher Reihenfolge, wer jeden verantwortet und freigibt und welche Nachweise dem Programm den Übergang von einem Zyklus zum nächsten erlauben. In einem S/4HANA-Programm umfasst sie meist Unit- und String-Tests, SIT-Runden, UAT-Runden, Regression, Tests der Datenmigration und Cutover-Generalproben.

Welchen Anteil eines S/4HANA-Programms macht das Testen aus?

In den Programmen, die ich plane, beanspruchen Tests rund 35 Prozent des Programmaufwands. Budgetieren Sie sie von Anfang an auf diesem Niveau, denn unterfinanziertes Testen wird als Erstes gekürzt, wenn der Build sich verspätet.

Wie lange sollte der UAT in einem S/4HANA-Projekt dauern?

Mindestens 6 bis 8 Wochen. Fachliche Tester führen den UAT neben ihrer normalen Arbeit durch und brauchen Zeit für mehr als eine Runde, damit Korrekturen aus der ersten Runde erneut getestet werden.

Wer sollte den Benutzerakzeptanztest in SAP verantworten?

Der Fachbereich, über namentlich benannte Prozessverantwortliche. Der Systemintegrator kann Skripte vorbereiten, die Umgebung betreuen und Fehler beheben, aber nur die Leute, die die Prozesse betreiben, können bestätigen, dass das System für sie funktioniert.

Was sind Eingangs- und Ausgangskriterien bei SAP-Tests?

Eingangskriterien sind die Bedingungen, die ein Zyklus braucht, bevor er beginnt, etwa abgeschlossene Unit-Tests, eine aufgebaute Umgebung und geladene Testdaten. Ausgangskriterien sind die Bedingungen, die er erfüllen muss, bevor er endet, etwa ausgeführte Skripte, keine offenen kritischen Fehler und die Freigabe durch die Prozessverantwortlichen. Jedes sollte eine Ja-oder-Nein-Antwort liefern und einen namentlich benannten Unterzeichner haben.

Was sollte eine S/4HANA-Go-live-Checkliste enthalten?

Technische Cutover-Schritte, Datenladungen und Abstimmungen, fachliche Validierungen, Umschaltungen von Schnittstellen, Benutzerzugänge und die Go/No-Go-Entscheidungspunkte. Vereinbaren Sie sie vorab, üben Sie sie in den Probekonvertierungen oder der Generalprobe und gehen Sie nur live, wenn jeder Punkt erledigt und unterschrieben ist.