Warum SAP anders ist

Wer Web-Apps automatisiert hat, unterschätzt SAP fast immer. Die Oberflächen (SAP GUI, Fiori, teils beides gemischt) verhalten sich anders als HTML-Frontends, Geschäftsprozesse laufen über Module und Rollen hinweg (ein Order-to-Cash-Prozess berührt SD, MM und FI), und mit jedem Transport ändert sich das System unter den Tests. Selektor-basierte Skripte, die im Web funktionieren, werden hier zur Dauerbaustelle.

Was ein modellbasierter Ansatz ändert

Tricentis Tosca ist für genau diese Umgebung gebaut: Statt Klickpfade aufzuzeichnen, modelliert man die Anwendung einmal in wiederverwendbaren Modulen; ändert sich ein Bildschirm, wird ein Modul aktualisiert statt fünfzig Skripte. Die SAP-Engines verstehen SAP GUI und Fiori ab Werk, und die Module überleben Upgrades deutlich besser als aufgezeichnete Abläufe. Das ist der Kern des modellbasierten Testens, und in SAP-Landschaften zahlt er sich am stärksten aus.

Testen, was ein Transport wirklich betrifft

Die zweite SAP-Besonderheit ist der Änderungstakt. Wer nach jedem Transport die komplette Regression fährt, verbrennt Zeit; wer nur rät, übersieht Risiken. Change-Impact-Analyse mit LiveCompare zeigt, welche Objekte und Prozesse eine Änderung tatsächlich berührt, und macht aus der Regression eine gezielte, kleine Auswahl. In Kombination mit automatisierten Suiten entsteht so ein Regressionsbetrieb, der mit dem Release-Takt mithält.

Die Erfolgsfaktoren aus der Praxis

  • Risikobasiert priorisieren: zuerst die End-to-End-Prozesse mit der grössten finanziellen und operativen Wirkung, nicht die einfachsten Transaktionen.
  • Modular bauen: wiederverwendbare Module und Templates statt Einweg-Aufzeichnungen; das entscheidet über die Wartungskosten im zweiten Jahr.
  • Testdaten von Anfang an mitdenken: SAP-Tests brauchen Stammdaten, Buchungen und Berechtigungen in reproduzierbarem Zustand.
  • In die Pipeline integrieren: Läufe, die automatisch starten und dorthin berichten, wo das Team ohnehin hinschaut.

Was ein Repository-Review typischerweise findet

Die meisten Tosca-Probleme sind im Repository sichtbar, lange bevor sie als Wartungskosten auftauchen. Aus einem anonymisierten Repository-Review in einem unserer Health Checks:

  • 81 Minuten statische Wartezeiten pro Lauf: 77 davon aus einer einzigen Vorbedingung, einer 45-Sekunden-Wartezeit, die sich in 103 Testfällen wiederholt. Ersetzt man sie in einem wiederverwendbaren Baustein durch eine dynamische Synchronisation, fällt der Grossteil dieser Zeit weg.
  • 12 Prozent ungenutzte Module: 24 von 195 Modulen wurden weiter gepflegt, ohne dass ein Testfall sie nutzte.
  • 107 deaktivierte Testschritte: in aktiven Testfällen mitgeschleppt, Rauschen in jedem Lauf, und darunter können abgeschaltete Prüfungen sein.
  • 35 Prozent Module mit nur einem Attribut: 68 von 195 Modulen, also wenig Wiederverwendung und hoher Wartungsaufwand.

Nichts davon ist exotisch. So sieht ein Repository aus, das ohne Review-Konventionen gewachsen ist, und sobald es sichtbar ist, lässt sich das meiste schnell beheben.

Zwei Beispiele aus unseren Projekten

Ein Template, 70 Werke. Für einen globalen Energietechnik-Hersteller, dessen Produktion auf SAP Digital Manufacturing läuft (integriert mit PP, MM und FI/CO), haben wir das manuelle Testen Werk für Werk durch ein einziges Tosca-Regressionstemplate ersetzt. Gebaut und validiert für 10 Pilotwerke, wurde es anschliessend auf 70 Werke weltweit ausgerollt, mit einheitlichen Testdaten für jedes Werk und CI/CD über Jenkins. Jedes weitere Werk nutzt dasselbe Template, statt neu anzufangen (Fallstudie).

SAP IS-U im Release-Rhythmus. Für eine kommunale Versorgungsgruppe automatisieren wir die SAP-IS-U-Prozesse ihrer Netzgesellschaft end-to-end in Tosca: Marktkommunikation, Online-Services, Zählermontage und Hausanschlüsse. Über das gesamte Mandat laufen heute 240 Geschäftsprozesse als automatisierte Regression, und die Fachbereiche brauchen pro Release 65 Prozent weniger Testaufwand (Fallstudie).

Unsere Einschätzung

SAP-Testautomatisierung scheitert selten am Tool und oft am Zuschnitt: zu breit gestartet, zu wenig modular gebaut, Testdaten vergessen. Richtig aufgesetzt trägt eine Tosca-Automatisierung durch Upgrades, Transporte und selbst eine S/4HANA-Migration. Wie wir das angehen, steht auf unserer Seite zum SAP-Testing; wenn Sie wissen wollen, wo Ihre SAP-Regression heute steht, ist ein QA Health Check der schnellste Einstieg.