SAP-Tests erklärt: Testarten, Phasen und Verantwortliche

SAP-Tests sind die Arbeit, mit der Sie belegen, dass ein konfiguriertes SAP-System Ihre Geschäftsprozesse korrekt abbildet, mit Ihren Daten und in Ihren Volumen, vor dem Go-live und nach jeder späteren Änderung. In einem S/4HANA-Programm umfassen sie sechs Testarten: Unit-Test, Integrationstest (SIT), Benutzerakzeptanztest (UAT), Regressionstest, Performancetest und Cutover-Generalprobe.

Jede Testart beantwortet eine andere Frage, und keine ersetzt eine andere. Nach meiner Erfahrung beanspruchen Tests rund 35 Prozent des Programmaufwands. Deshalb verdienen sie einen eigenen Plan, ein eigenes Budget und eigene Verantwortliche statt ein paar Wochen am Ende der Realisierung.

Diese Seite ist der Überblick. Jede Testart hat einen eigenen Leitfaden, verlinkt in den Abschnitten unten.

Ein SAP-System besteht aus Konfiguration, Stammdaten, Eigenentwicklungen und Schnittstellen, die zusammenwirken. Eine Änderung an einer Stelle kann einen Prozess an einer ganz anderen Stelle brechen, oft in einem Modul, das niemand angefasst hat.

Deshalb sind SAP-Tests an Geschäftsprozessen ausgerichtet, nicht an Bildschirmen. Order-to-Cash, Procure-to-Pay und Record-to-Report laufen über mehrere Module, und ein Test, der bei einer einzelnen Transaktion endet, beweist sehr wenig.

Mit dem Go-live endet das Testen auch nicht. Supportänderungen, SAP-Releases und neue Rollouts verändern das System laufend, also geht dieselbe Disziplin in der Run-Phase weiter.

Diese sechs Testarten plane ich in einem S/4HANA-Programm ein. Die Tabelle zeigt, was jede belegt, wann sie läuft und wer sie verantworten sollte.

Testart	Was sie belegt	Wo sie in SAP Activate liegt	Wer sie verantwortet
Unit-Test	Jedes Konfigurationselement, jedes Programm und jede Erweiterung funktioniert für sich	Realize, innerhalb jedes Build-Sprints	Funktionale und technische Berater
Integrationstest (SIT)	Komplette Prozesse laufen über Module und Schnittstellen hinweg mit realistischen Daten	Realize, in Runden, sobald der Build stabil ist	Testleiter des Programms, mit den Prozessverantwortlichen
Benutzerakzeptanztest (UAT)	Der Fachbereich kann seine realen Szenarien im System abwickeln	Spätes Realize, vor Deploy	Der Fachbereich
Regressionstest	Was vorher funktioniert hat, funktioniert auch nach einer Änderung	Ab Realize, danach bei jedem Release in Run	Testleiter, mit Automatisierung, wo das Volumen es rechtfertigt
Performancetest	Das System hält vielen gleichzeitigen Anwendern und Produktionsvolumen stand	Realize, abgeschlossen vor dem Go-live	Performanceverantwortlicher auf Programmebene mit Basis
Cutover-Generalprobe	Go-live-Ablauf, Datenladungen und Zeitplan funktionieren durchgängig	Deploy	Cutover-Manager

SAP-Tests über SAP Activate hinweg

1. 01

   Prepare

   Testtool, Team und Testlandschaft aufsetzen.

2. 02

   Explore

   Die Teststrategie schreiben, während die Fit-to-Standard-Entscheidungen fallen, damit Anforderungen testbar sind.

3. 03

   Realize

   Unit-Tests in den Sprints, dann SIT-Runden, Performancetests und UAT, sobald der Build stabil ist.

4. 04

   Deploy

   Cutover-Generalproben gegen eine vereinbarte Checkliste, dann die Go-live-Entscheidung.

5. 05

   Run

   Regressionstests für jede Supportänderung, jedes Upgrade und jedes Release.

Unit-Test

Den Unit-Test machen die Leute, die das Element gebaut haben. Ein funktionaler Berater prüft eine Preiskondition, ein Entwickler prüft eine Erweiterung oder ein Schnittstellen-Mapping.

Er ist notwendig, aber nicht ausreichend. Ein sauberer Unit-Test sagt nichts darüber, was passiert, wenn dieses Element auf den Rest des Prozesses trifft.

Integrationstest

Im SIT erfährt das Programm, ob das Design funktioniert. Ein Kundenauftrag muss in Lieferung, Fakturierung, Buchhaltung und Reporting durchlaufen, und jede Schnittstelle auf dem Weg muss korrekt buchen.

Ich plane den SIT in Runden, nicht als einen einzigen Durchlauf. Fehler aus der ersten Runde werden behoben, und die nächste Runde belegt, dass die Korrekturen nichts anderes beschädigt haben. Wie Runden, Eingangs- und Ausgangskriterien zusammenpassen, steht in meinem Leitfaden zur S/4HANA-Teststrategie.

Benutzerakzeptanztest

Im UAT bestätigt der Fachbereich, dass das System die Arbeitsweise nach dem Go-live unterstützt. Er gehört dem Fachbereich, nicht dem Systemintegrator, denn nur der Fachbereich kann das System abnehmen.

Der UAT braucht mindestens 6 bis 8 Wochen. Wer ihn zusammenpresst, damit er zu einem verspäteten Build passt, bekommt eine Freigabe auf dem Papier und Probleme in der Produktion. Mein Leitfaden zum SAP-Benutzerakzeptanztest behandelt Testskripte, Rollen und Freigabe.

Regressionstest

Der Regressionstest wiederholt bewährte Tests nach einer Änderung, um alles zu finden, was die Änderung beschädigt hat. In einem langen Programm laufen Korrekturen aus dem Live-Support und Projektänderungen gleichzeitig durch das System.

Mein Ansatz sind zwei getrennte Landschaften, eine für das Projekt und eine für den laufenden Betrieb (BAU). Live-Supportänderungen und Projektänderungen werden dann getrennt getestet, und keine verdeckt einen Fehler in der anderen. Mein Leitfaden zum SAP-Regressionstest behandelt den Ansatz mit zwei Landschaften, Upgrades und Auswirkungsanalyse.

Performancetest

Der Performancetest muss vor dem Go-live stattfinden. Am wichtigsten sind Parallelitätstests, bei denen viele Anwender im selben Moment Transaktionen ausführen.

Eine Transaktion, die für einen Anwender korrekt läuft, kann bei zweihundert in einen Timeout laufen. Funktionale Tests zeigen Ihnen das nie. Mein Leitfaden für IT-Verantwortliche zu SAP-Performancetests behandelt Last-, Stress- und Dauertests und wie Sie Abnahmekriterien formulieren.

Cutover-Generalprobe

Die Cutover-Generalprobe testet den Go-live selbst: die Abfolge der technischen Schritte, Datenladungen, Abstimmungen und Freigaben, mit Zeitplan. Bei einer Brownfield-Konvertierung plane ich drei Probekonvertierungen vor dem Cutover.

Das Go-live-Kriterium, auf dem ich bestehe, ist eine ausführliche Cutover-Checkliste, die vorab vereinbart ist. Wird die Checkliste erst am Cutover-Wochenende geschrieben, waren die Generalproben keine echten Generalproben.

Tests beanspruchen nach meiner Erfahrung rund 35 Prozent des Programmaufwands. Diese Zahl überrascht Sponsoren, die das Testen für die kurze Lücke zwischen Build und Go-live halten.

Der Aufwand verteilt sich auf viele Personen. Berater führen Unit-Tests durch, ein Testteam bereitet den SIT vor und führt ihn aus, Fachanwender führen den UAT durch, und Basis- und Integrationsteams unterstützen Performancetests und Cutover-Generalproben.

Die Datenmigration läuft parallel und beansprucht allein 30 bis 40 Prozent des Aufwands. Beides überschneidet sich stark, denn jede Testrunde braucht migrierte Daten, die wie Produktionsdaten aussehen.

Der häufigste Testfehler, den ich sehe, ist schlicht zu wenig Testen in SIT und UAT. Runden werden gestrichen, wenn der Build sich verspätet, und der Go-live-Termin bleibt, wo er war. Über die 21 SAP-Programme, die ich geleitet oder gerettet habe, ist der größte Fehler nach wie vor, am Anfang nicht sauber zu planen, und beim Testen zeigt sich das meist zuerst.

Tests sind nur so gut wie die Daten, auf denen sie laufen. Meine Regel: maskierte Daten, aber auf Produktionsniveau. Also Volumen in Produktionsgröße und realistische Datensätze, bei denen personenbezogene und sensible Felder maskiert sind.

Kleine, saubere Testdaten verbergen genau die Probleme, die zählen. Ein Bericht, der auf ein paar tausend Datensätzen in Sekunden läuft, kann auf einem vollen Jahr an Buchungen Stunden brauchen.

Die Umgebung zählt so viel wie die Daten. Planen Sie die Testlandschaft in Prepare, legen Sie fest, wie sie zwischen den Runden aufgefrischt wird, und halten Sie Projekt- und BAU-Änderungen auseinander. Mein Leitfaden zum SAP-Testdatenmanagement behandelt Kopien, Maskierung und selektive Testdaten.

Meine Regel zur Automatisierung ist einfach. Wenn es sehr viele Testfälle gibt, die umfangreich und wiederholt getestet werden müssen, automatisieren Sie. Darunter ist manuelles Testen in Ordnung.

Beim Regressionstest zahlt sich Automatisierung meist zuerst aus, weil dieselben Tests nach jeder Änderung laufen. Der UAT bleibt weitgehend manuell, denn sein Zweck ist das Urteil eines Fachanwenders, nicht das eines Skripts.

Es gibt einen praktischen Grund, früh zu entscheiden. Automatisierte Tests brauchen Zeit für Aufbau und Pflege, also rechnen sie sich nur, wenn sie oft laufen. Mein Leitfaden zur SAP-Testautomatisierung behandelt, wo Sie anfangen und wann es sich auszahlt.

Die Tools fallen in drei Gruppen: Testmanagement, funktionale Automatisierung und Performancetests. Teams, die ich geleitet oder mit denen ich gearbeitet habe, haben Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath und LoadRunner eingesetzt.

Das leistet jede Gruppe, mit den Produkten darin:

Toolgruppe	Was sie leistet	Produkte, die Teams häufig nutzen
Testmanagement	Testpläne, Testfälle, Durchführungsnachweise, Fehler und Rückverfolgbarkeit zu den Anforderungen	SAP Cloud ALM, SAP Solution Manager, Panaya
Funktionale Testautomatisierung	Führt skriptbasierte oder modellbasierte Tests über SAP- und Nicht-SAP-Anwendungen aus	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
Performancetests	Simuliert viele gleichzeitige Anwender und Produktionsvolumen	OpenText LoadRunner, heute vertrieben als OpenText Professional Performance Engineering

Einige Produktfakten sollten Sie kennen, bevor Sie wählen.

1. SAP Cloud ALM ist für Kunden mit SAP Enterprise Support oder einem Cloud-Abonnement mit Enterprise Support, cloud editions, enthalten (SAP Support). Das Testmanagement umfasst Testvorbereitung, Testpläne und Durchführung, einschließlich manueller Testfälle für den UAT (SAP Learning).
2. SAP Solution Manager 7.2: Die Mainstream-Wartung endet Ende 2027, mit optionaler erweiterter Wartung bis Ende 2030 für einen Teil der Funktionen, darunter die Test Suite (SAP Support).
3. SAP Test Automation by Tricentis ist das von SAP vertriebene Automatisierungsprodukt, integriert in SAP Cloud ALM und gebaut für SAP- und Drittsysteme (SAP).
4. LoadRunner ist ein Produkt von OpenText. LoadRunner Professional heißt heute OpenText Professional Performance Engineering und unterstützt die Protokolle SAP GUI und SAP Web (OpenText).

Wenn Sie ein neues Programm starten, planen Sie das Testmanagement in Cloud ALM statt im Solution Manager. Einen tieferen Vergleich finden Sie in meinem Leitfaden zu SAP-Testtools.

Bei SAP Cloud ERP public edition (S/4HANA Cloud Public Edition) aktualisiert SAP jeden Kunden nach eigenem Zeitplan. SAP Learning beschreibt Upgrades alle sechs Monate, derzeit im Februar und August, mit neuen Funktionen, die dazwischen monatlich ausgeliefert werden (SAP Learning).

Sie wählen den Upgrade-Termin nicht selbst, also wird der Regressionstest zu einem festen Kalendertermin statt zu einem Projekt. Das ist das stärkste Argument, den Regressionstest auf einem Public-Cloud-System früh zu automatisieren.

In der Private Cloud und On-Premise steuern Sie den Zeitpunkt der Upgrades selbst. Jedes braucht trotzdem einen Regressionszyklus, der auf die Prozesse zugeschnitten ist, die die Änderung berührt.

Bevor Sie irgendetwas anderes tun, nehmen Sie das Testen als Workstream mit eigenem Verantwortlichen und eigenem Budget in den Plan auf, bemessen mit rund einem Drittel des Aufwands. Benennen Sie dann den Verantwortlichen im Fachbereich für den UAT und blocken Sie jetzt 6 bis 8 Wochen dafür im Kalender, bevor der Build sie zusammendrückt.

Verknüpfen Sie Testergebnisse über messbare Ausgangskriterien mit Ihren Go/No-Go-Entscheidungen. Wie das geht, zeigt mein Leitfaden zu SAP Quality Gates. Steckt Ihr Programm bereits in Schwierigkeiten, behandeln meine Notizen zur Rettung von SAP-Programmen, was Sie zuerst beheben sollten.

Wenn Sie eine unabhängige Sicht auf eine Teststrategie oder eine Go-live-Entscheidung möchten: Dabei unterstütze ich Organisationen. Sie können mich hier kontaktieren.

Was sind SAP-Tests?

SAP-Tests belegen, dass ein konfiguriertes SAP-System Ihre Geschäftsprozesse korrekt abbildet, mit Ihren Daten und in Ihren Volumen. In einem S/4HANA-Programm umfassen sie Unit-Test, Integrationstest, Benutzerakzeptanztest, Regressionstest, Performancetest und Cutover-Generalprobe. Nach dem Go-live gehen sie für jede Supportänderung und jedes Release weiter.

Welche Arten von SAP-Tests gibt es?

Die sechs wichtigsten Testarten sind Unit-Test, Integrationstest (SIT), Benutzerakzeptanztest (UAT), Regressionstest, Performancetest und Cutover-Generalprobe. Unit-Tests prüfen einzelne Elemente, der SIT prüft komplette Prozesse über Module und Schnittstellen, und im UAT nimmt der Fachbereich das System ab. Regressionstest, Performancetest und Cutover-Generalprobe schützen vor den Folgen von Änderungen, Last und dem Go-live selbst.

Wie lange dauert ein SAP-Benutzerakzeptanztest?

Planen Sie mindestens 6 bis 8 Wochen für den UAT. Der Fachbereich sollte ihn verantworten, seine realen Szenarien durchspielen und ihn freigeben. Zu wenig Testen in UAT und SIT ist der häufigste Testfehler, den ich sehe.

Welchen Anteil eines SAP-Projekts macht das Testen aus?

Nach meiner Erfahrung beansprucht das Testen rund 35 Prozent des Programmaufwands. Das umfasst Vorbereitung und Durchführung von Unit-Tests, SIT-Runden, UAT, Regressionstests, Performancetests und Cutover-Generalproben. Die Datenmigration läuft parallel und braucht für jede Testrunde produktionsnahe Daten.

Sollten SAP-Tests automatisiert werden?

Automatisieren Sie, wenn Sie sehr viele Testfälle haben, die umfangreich und wiederholt getestet werden müssen, und das betrifft meist den Regressionstest. Darunter ist manuelles Testen in Ordnung. Der UAT bleibt weitgehend manuell, denn sein Zweck ist das Urteil des Fachbereichs.

Welches Tool wird für SAP-Tests verwendet?

Die meisten Programme kombinieren ein Testmanagement-Tool mit einem Automatisierungstool und einem Tool für Performancetests. Übliche Wahl sind SAP Cloud ALM oder Solution Manager für das Testmanagement, Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft oder UiPath für die Automatisierung und OpenText LoadRunner für die Performance. Neue Programme sollten mit Cloud ALM planen, da die Mainstream-Wartung des Solution Manager 2027 endet.