SAP-Testautomatisierung: wo Sie anfangen und wann sie sich lohnt

SAP-Testautomatisierung heißt, die SAP-Tests, die Sie immer wieder ausführen, vor allem Regressionstests, in Tests zu verwandeln, die ein Tool statt Menschen ausführt. Sie lohnt sich, wenn sehr viele Testfälle umfangreich und wiederholt getestet werden müssen. Darunter ist manuelles Testen in Ordnung.

Das ist die Regel, die ich in S/4HANA-Programmen anwende. Nach meiner Erfahrung beanspruchen Tests rund 35 Prozent des Programmaufwands, die Frage ist also nie, ob getestet wird. Die Frage ist, welchen Teil dieses Aufwands ein Tool tragen sollte.

Wie sich Automatisierung neben Unit-, Integrations-, Akzeptanz- und Performancetests einfügt, zeigt mein Überblick SAP-Tests erklärt. Dieser Artikel behandelt, wo Sie anfangen, wann sich Automatisierung lohnt, die Frameworks und was SAP Cloud ALM, Solution Manager und Tricentis Ihnen bieten.

Meine Regel 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.

Der Grund liegt in der Kostenstruktur. Ein automatisierter Test kostet im Aufbau mehr als ein einmaliger manueller Durchlauf, und er braucht Pflege, sobald sich Prozess, Bildschirm oder Daten ändern. Das holen Sie nur über Wiederholung wieder herein.

In einem SAP-Programm kommt die Wiederholung aus vorhersehbaren Quellen:

1. Transporte. Jede Änderung, die ins Qualitätssicherungssystem geht, kann etwas brechen, das gestern noch funktioniert hat.
2. SAP-Releases und Support Packages. Upgrades On-Premise und in der Private Cloud sowie die planmäßigen Upgrades bei SAP S/4HANA Cloud Public Edition.
3. Wiederholte Testrunden. Der Integrationstest (SIT) führt dieselben durchgängigen Abläufe in mehr als einer Runde aus.
4. Rollout-Wellen. Ein globales Template wird für jedes Land oder jeden Buchungskreis erneut getestet.
5. Datenintensive Prüfungen. Viele Kombinationen aus Preisfindung, Steuer- oder Kontenfindung, bei denen sich nur die Daten ändern.

Trifft keiner dieser Punkte zu, kostet Sie ein Tool mehr, als es spart.

Die Tabelle zeigt, wie ich die Arbeit nach Testart aufteilen würde.

Testart	Automatisieren?	Warum
Regression der Kernprozesse wie Order-to-Cash, Procure-to-Pay und Record-to-Report	Ja, zuerst	Läuft nach jedem Transport und jedem Release
SIT-Runden	Teilweise	Stabile Abläufe automatisieren, neue und sich ändernde Szenarien manuell lassen
Benutzerakzeptanztest (UAT)	Selten	Fachanwender beurteilen, ob der Prozess für sie funktioniert, und das kann kein Skript
Explorative und Negativtests	Nein	Der Wert entsteht, weil ein Mensch nach dem sucht, was niemand geskriptet hat
Performance und Last	Ja, mit einem Lasttool	Viele gleichzeitige Anwender lassen sich nicht von Hand erzeugen
Einmalige Prüfungen der Datenmigration	Meist nicht	Abstimmberichte leisten das besser, es sei denn, dieselbe Ladung wiederholt sich über die Probeläufe hinweg

Decide

Sollten Sie diesen SAP-Test automatisieren?

Viele Testfälle, wiederholt nach jeder Änderung oder jedem Release

→Automatisieren

Wenige Testfälle oder nur ein- bis zweimal ausgeführt

→Manuell testen

Prozessdesign ändert sich noch

→Warten, bis es stabil ist, dann entscheiden

Enttäuschende Automatisierung hat meist zu breit angefangen: alles auf einmal, während des Designs, und niemand verantwortet das Ergebnis. Diese Reihenfolge würde ich einhalten:

1. Wählen Sie die Prozesse, deren Ausfall sich der Fachbereich nicht leisten kann. Monatsabschluss, Fakturierung, Zahlungen und alles, was über viele Standorte ausgerollt wird, kommen vor wünschenswerten Berichten.
2. Führen Sie die Tests zuerst manuell aus. Ein Tool automatisiert einen Test, der von Hand bereits funktioniert. Es entwirft keinen für Sie.
3. Warten Sie auf ein stabiles Design. Wer während Explore oder frühem Realize automatisiert, baut die Tests bei jeder geänderten Designentscheidung neu.
4. Bauen Sie ein kleines Regressionspaket. Decken Sie die kritischen Prozesse durchgängig ab und lassen Sie das Paket bei jedem Transport ins Qualitätssicherungssystem laufen.
5. Benennen Sie einen Verantwortlichen für die Pflege. Jemand muss die Tests reparieren, wenn sich Bildschirme, Rollen oder Daten ändern, sonst verfällt das Paket innerhalb weniger Releases.
6. Erweitern Sie die Abdeckung nur, wo Wiederholung es rechtfertigt. Nehmen Sie einen Test auf, wenn er oft laufen wird, nicht weil eine Abdeckungsquote es verlangt.

Projekt und laufenden Betrieb trennen

Während eines Programms betreibe ich 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.

Für die Automatisierung ist das wichtig. Schlägt ein Regressionstest fehl, wollen Sie eine einzige Änderungsquelle untersuchen, nicht zwei vermischte. Mein Leitfaden zum SAP-Regressionstest behandelt den Ansatz mit zwei Landschaften und die Auswirkungsanalyse ausführlicher.

In meinen Programmen habe ich Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath und LoadRunner eingesetzt oder von meinen Teams einsetzen lassen. Dieser Artikel stellt keine Rangliste auf. Die richtige Wahl hängt von Ihrer Landschaft ab, von Ihrem Supportvertrag und davon, wer die Tests pflegen wird.

Beginnen Sie mit dem, was SAP bereits bereitstellt, denn ein Teil davon ist womöglich schon bezahlt.

SAP Cloud ALM

SAP Cloud ALM ist die Ebene für das Testmanagement. Es plant, führt aus und verfolgt manuelle und automatisierte Tests gegen Ihre Prozesse und Anforderungen. Kunden mit SAP Enterprise Support, Product Support for Large Enterprises oder einem berechtigten Cloud-Abonnement können einen Tenant bereitstellen (SAP-Nutzungsrechte).

Automatisierte Tests führt es selbst nicht aus. SAP stellt klar, dass Cloud ALM keine eigene Automatisierungs-Engine hat und dass seine ALM-Plattformen für Testautomatisierung von Drittanbietern offen bleiben (SAP Support, Testautomatisierung).

Der Einrichtungsleitfaden von SAP beschreibt integrierte Anbindungen sowie eine öffentliche Test Automation API für andere Anbieter (SAP Help Portal). Panaya und UiPath dokumentieren Cloud-ALM-Integrationen für automatisierte Testfälle. Worksoft führt Cloud ALM und Solution Manager unter seinen Integrationen, und OpenText bietet eine Cloud-ALM-Integration für sein Cloud-Produkt für Performancetests.

Tricentis Test Automation for SAP und SAP Test Automation by Tricentis

Prüfen Sie Ihren Anspruch, bevor Sie irgendetwas kaufen. SAP gewährt eine befristete Lizenz für Tricentis Test Automation for SAP, integriert in Cloud ALM, mit SAP Enterprise Support, Enterprise Support cloud editions und Product Support for Large Enterprises. Sie läuft derzeit bis zum 31. Dezember 2028 (SAP-Nutzungsrechte).

Die Grenzen sind eng: 5 namentlich benannte Anwender, 500 Testläufe pro Kalendermonat, 5 vom Kunden betriebene Ausführungsagenten und 12 Monate Aufbewahrung der Ergebnisse. Sie darf nicht zur Automatisierung produktiver Geschäftsprozesse genutzt werden. Sehen Sie darin einen Einstieg, kein Tool für Programmgröße.

SAP Test Automation by Tricentis ist die kostenpflichtige nächste Stufe. Es ist ein Software-as-a-Service-Produkt, das SAP als Solution Extension verkauft und unterstützt, für SAP- und Drittanwendungen. Es erweitert die in Cloud ALM enthaltene Tricentis-Funktion, wenn der Anspruch nicht mehr ausreicht.

SAP Solution Manager

Die Mainstream-Wartung des Solution Manager 7.2 läuft bis Ende 2027. Kunden, die sich für die erweiterte Wartung der SAP Business Suite 7 entscheiden, erhalten erweiterte Wartung für den Solution Manager bis Ende 2030. Sie deckt einen begrenzten Satz an Bereichen ab, darunter die Test Suite (SAP Support).

Seine eigene Automatisierung, Component-Based Test Automation (CBTA), wird nicht auf SAP-Cloud-Produkte erweitert. Die Tricentis-Lizenz für die Solution-Manager-Integration läuft derzeit bis zum 31. Dezember 2027. Wenn Sie den Solution Manager bereits betreiben, behalten Sie ihn, bis Ihre Landschaft umzieht, aber bauen Sie keine neue Automatisierung darauf auf.

SAP S/4HANA Cloud Public Edition

Die Public Edition bringt ihr eigenes Test Automation Tool mit. Die Empfehlung von SAP lautet, dass Partner Testautomaten anlegen oder aktualisieren, während sie jeden Prozess konfigurieren, damit diese bei Upgrades im Testsystem laufen können (SAP Learning).

Mit Ihrer Zustimmung führt SAP nach dem Upgrade Tests für unveränderte Standardprozesse aus. Nach dem Go-live verantworten Sie den Regressionstest für alles, was Sie angepasst haben, mit Ihren eigenen Testautomaten.

Die Tabelle fasst die oben genannten Tools nach Aufgabe zusammen, nicht nach Präferenz.

Tool	Hauptaufgabe	Wo es passt
SAP Cloud ALM	Testmanagement und Orchestrierung	Neue Programme; verbindet manuelle und automatisierte Tests mit Prozessen
SAP Solution Manager	Testmanagement, On-Premise	Landschaften, die ihn bereits betreiben; Mainstream-Wartung endet 2027
Tricentis Tosca und SAP Test Automation by Tricentis	Modellbasierte Automatisierung	SAP- und Nicht-SAP-Anwendungen; von SAP vertrieben und unterstützt
Worksoft	Codefreie Prozessautomatisierung	Integriert mit Cloud ALM und Solution Manager
Panaya	Testmanagement und codefreie Automatisierung	Cloud-ALM-Integration für automatisierte Tests
UiPath	Automatisierungsplattform mit Test Manager	Cloud-ALM-Integration für automatisierte Testfälle
OpenText LoadRunner	Performance- und Lasttests	Parallelitäts- und Volumentests vor dem Go-live

Einen tieferen Vergleich, einschließlich Xray for Jira, finden Sie in meinem Leitfaden zu SAP-Testtools. Zu Lasttests lesen Sie SAP-Performancetests für IT-Verantwortliche.

Das Tool zählt weniger als die Art, wie die Tests gebaut werden, und wer sie pflegt. Die meiste SAP-Automatisierung folgt einem dieser Ansätze:

1. Modellbasiert. Bildschirme und APIs werden in wiederverwendbare Module eingescannt und dann zu Testfällen zusammengesetzt. Funktionale Berater können sie ohne Code bauen und lesen.
2. Codefreie Prozessaufzeichnung. Geschäftsprozessschritte werden aufgezeichnet und in wiederverwendbare Tests umgewandelt. Das passt zu Teams, in denen Key User beim Aufbau des Regressionspakets helfen.
3. Codebasiert. Testingenieure schreiben Tests in einem Programmier-Framework. Das passt zu Fiori-Apps und APIs, die einem Entwicklungsteam gehören, und braucht Entwickler für die Pflege.
4. Plattformen für Robotic Process Automation mit Testmodulen. Eine Plattform für Geschäftsautomatisierung und Testautomatisierung, nützlich, wenn Sie sie bereits betreiben.
5. Von SAP gelieferte Testautomaten. In der Public Edition die mit dem Test Automation Tool gelieferten Testautomaten, angepasst an Ihre Daten und Änderungen.

Welchen Ansatz Sie auch wählen, drei Designentscheidungen bestimmen, ob die Tests überleben:

1. Testen Sie auf API-Ebene, wo es geht. API-Tests brechen seltener als Tests, die sich durch Bildschirme klicken.
2. Halten Sie Testdaten zurücksetzbar. Ein Test, der von Daten abhängt, die der letzte Lauf verbraucht hat, schlägt aus dem falschen Grund fehl.
3. Bauen Sie aus gemeinsamen Modulen. Ändert sich ein Bildschirm, reparieren Sie ein Modul, nicht jeden Test, der ihn berührt.

Ein automatisiertes Regressionspaket ist ein Produkt, kein Projektergebnis. Es braucht einen Verantwortlichen, eine Budgetposition und einen Platz im Änderungsprozess.

Binden Sie es an das Change Control. Kein Transport geht in die Produktion, bevor das Regressionspaket gelaufen ist und seine Ergebnisse im Testmanagement-Tool erfasst sind. Mein Artikel zu SAP Quality Gates zeigt, wie Testergebnisse Teil einer Go/No-Go-Entscheidung werden.

Planen Sie auch den Release-Rhythmus von SAP ein. Upgrades der Public Edition kommen nach dem Zeitplan von SAP, nicht nach Ihrem, und Private-Cloud- und On-Premise-Systeme brauchen weiterhin Support Packages und Upgrades. Jedes davon ist ein Regressionslauf, und genau dort holt die Automatisierung ihre Kosten wieder herein.

Reparieren Sie instabile Tests, nehmen Sie Tests außer Betrieb, die niemand ausführt, und halten Sie das Paket so klein, dass die Leute seinen Ergebnissen vertrauen.

Automatisierung muss außerdem in einem Testplan verankert sein. Zyklen, Eingangs- und Ausgangskriterien und Rollen kommen zuerst; meine S/4HANA-Teststrategie legt sie dar.

Listen Sie die Geschäftsprozesse auf, die Sie nach jedem Transport und jedem SAP-Release erneut testen würden. Zählen Sie die Testfälle dahinter und wie oft jeder davon pro Jahr laufen würde.

Ist die Zahl groß und wiederholen sich die Läufe, haben Sie ein Argument für Automatisierung. Prüfen Sie dann, was Ihr SAP-Supportvertrag bereits enthält, bevor Ihnen jemand eine Demo zeigt.

Wenn Sie eine unabhängige Sicht auf einen Plan zur Testautomatisierung oder ein Anbieterangebot möchten: Dabei unterstütze ich Organisationen. Sie können mich hier kontaktieren.

Was ist SAP-Testautomatisierung?

Der Einsatz eines Tools, um SAP-Tests auszuführen, die sonst von Hand laufen würden, vor allem Regressionstests nach Änderungen und Upgrades. Ein Testmanagement-Tool wie SAP Cloud ALM plant und dokumentiert die Tests, und ein Automatisierungstool führt sie aus.

Wann sollte man SAP-Tests automatisieren?

Wenn sehr viele Testfälle umfangreich und wiederholt getestet werden müssen, etwa als Regression nach jedem Transport, Release oder jeder Rollout-Welle. Darunter ist manuelles Testen in Ordnung. Warten Sie, bis das Prozessdesign stabil ist, sonst bauen Sie die Tests bei jeder Designänderung neu.

Kann SAP Cloud ALM Tests automatisieren?

Es verwaltet und startet automatisierte Tests, hat aber keine eigene Automatisierungs-Engine. Es integriert sich mit Tricentis Test Automation for SAP, mit dem Test Automation Tool in S/4HANA Cloud Public Edition und über eine öffentliche Test Automation API mit anderen Anbietern.

Was ist SAP Test Automation by Tricentis?

Ein Software-as-a-Service-Produkt für Testautomatisierung, das SAP als Solution Extension verkauft und unterstützt, für SAP- und Drittanwendungen. Es erweitert die Einstiegslizenz Tricentis Test Automation for SAP, die in SAP Enterprise Support enthalten ist. Diese Lizenz ist auf 5 namentlich benannte Anwender und 500 Testläufe pro Monat begrenzt.

Kann man den SAP-Benutzerakzeptanztest automatisieren?

Selten, und es sollte nicht das Ziel sein. Der UAT existiert, damit Fachanwender beurteilen, ob das System für sie funktioniert, und das kann kein Skript. Automatisieren Sie die wiederholte Regression drumherum und lassen Sie die Abnahmeentscheidung bei Menschen.

Sollte ich SAP Solution Manager noch für die Testautomatisierung nutzen?

Nur wenn er Ihre Landschaft bereits steuert. Die Mainstream-Wartung des Solution Manager 7.2 endet 2027, und seine CBTA-Automatisierung wird nicht auf SAP-Cloud-Produkte erweitert. Planen Sie neue Automatisierung rund um Cloud ALM.