SAP-Testing: Geschäftsprozesse bestimmen die Teststrategie

Was ist SAP-Testing?

SAP-Testing heißt, das eigene Testwissen auf ein System zu übertragen, das anders tickt als die meisten Softwareprojekte: hoch integriert, stark angepasst und mitten in den Kernprozessen des Unternehmens. Eine gute SAP-Teststrategie setzt deshalb bei den Geschäftsprozessen an, nutzt die Checkliste PRACTICES UP, damit kein Fokusbereich durchrutscht, und plant Testumgebung und Testdaten von Anfang an mit.

SAP unterscheidet sich von anderen IT-Systemen durch seine Komplexität, den Integrationsgrad und die Bedeutung für die Unternehmensprozesse. Es gilt als eines der führenden ERP-Systeme (Enterprise Resource Planning). Wer schon mal mit SAP-Projekten zu tun hatte, weiß: Da läuft einiges anders als in “normalen” Softwareprojekten. Die Bereitstellung, der Entwicklungszyklus, die Integration. Und eben auch der Test.

Das liegt zu einem guten Teil daran, wie ein ERP-System ins Haus kommt: weitgehend fertig. Das Team, das es einführt, programmiert weniger und beschäftigt sich mehr mit Konfiguration, Workflows, Daten und Berechtigungen. Der Test verschiebt sich mit. Klassische Unit-Tests treten zurück, Prozessprüfungen, Schnittstellentests, Abnahmetests, Ausgabeprüfungen und End-to-End-Tests rücken nach vorn.

Warum viele Tester einen Bogen um SAP machen

Ich kenne viele Tester und Testmanager, die einen großen Bogen um SAP-Projekte machen. Fragt man nach, steckt hinter dem Vorbehalt meist Unklarheit. Man weiß nicht so genau, wie was wann zu testen ist, welche Teststrategien sinnvoll sind und wo man anfangen soll. Dazu kommt die Tragweite. SAP geht ans Eingemachte: Die innersten Geschäftsprozesse laufen darüber, die Kerndaten des Unternehmens werden dort verarbeitet. Das birgt Risiken an vielen Stellen.

Ich habe das in zwei SAP-Projekten, die ich begleitet habe, am eigenen Leib erfahren. Da steckt viel Energie und Arbeit drin. Meine größte Frage war damals: Wie übertrage ich mein Wissen über Teststrategien, Testziele und Testmethoden in die SAP-Welt? Die Antwort kam erst nach den Projekten, als mir das Training “TMAP Quality Engineering for SAP” über den Weg lief. Beim Lesen der Unterlagen dachte ich: Ja genau, das hätte ich gebraucht. Umso wichtiger ist es, dass sich Tester und Testmanager mit SAP auseinandersetzen.

Wie überträgt man die eigene Testmethodik auf SAP?

Die bekannten Testmethoden gelten auch in SAP. Sie brauchen aber einen strukturierten Ansatz, der zur integrierten Natur des Systems passt. Drei Punkte prägen diesen Ansatz:

• Module greifen ineinander. Ein Geschäftsprozess läuft selten nur durch ein Modul. Von der Bestellung über die Lieferung bis zur Rechnung wandern die Daten durch mehrere Bereiche, oft auch in Systeme außerhalb von SAP. Der Test folgt deshalb dem Prozess von Anfang bis Ende, durch jedes Modul, das er berührt.
• Standard und Eigenbau. SAP liefert Standardfunktionen, die jedes Unternehmen per Customizing auf sich zuschneidet und oft um eigene Entwicklungen ergänzt. Beides braucht Tests, aber nicht im gleichen Umfang. Eigenentwicklungen sind das größere Risiko.
• Das Risiko bestimmt die Testtiefe. Je riskanter ein Prozess, desto gründlicher wird er getestet und desto früher ist er dran.

Bei den Testentwurfsverfahren gilt dieselbe Logik. Weil sich in SAP alles um Geschäftsprozesse und End-to-End-Abläufe dreht, bringen prozessorientierte Verfahren den größten Nutzen. Andere Verfahren haben weiter ihren Platz, meist früher im Lebenszyklus, im Unit- oder Systemtest.

Das Risiko entscheidet, was zuerst getestet wird

TMAP for SAP baut die Teststrategie aus drei Zutaten: der Checkliste PRACTICES UP, der Testbasis (User Stories, Prozessabläufe, fachliche Dokumente) und einer SAP-Qualitätsrisikoanalyse. Die Strategie speist dann Testplan, Testentwurf, Testdurchführung und die Quality Gates jeder Testphase. Der Testplan macht daraus Aktivitäten und einen Zeitplan.

Die Qualitätsrisikoanalyse läuft meist als Workshop mit Leuten aus Fachbereich und IT. Der Fachbereich bewertet jeden Prozess im Scope nach Nutzungshäufigkeit und geschäftlicher Auswirkung, die IT nach Prozesskomplexität und technischer Auswirkung. Zusammen ergibt das für jeden Prozess eine Risikoklasse.

Die Risikoklasse entscheidet zweierlei: wie intensiv ein Prozess getestet wird und wann. Kritische Prozesse kommen zuerst, mindestens mit ihrem Happy Flow in einer frühen Runde des Systemintegrationstests. Niedrigere Risikoklassen folgen in späteren Zyklen. Auch die Art des Projekts zählt, denn Einführung, Rollout und Upgrade brauchen jeweils andere Elemente in der Strategie.

PRACTICES UP: elf Fokusbereiche auf einer Checkliste

Ich bin ein großer Freund von leicht verständlichen Checklisten. PRACTICES UP ist so eine Checkliste, und zwar für die SAP-Teststrategie. Das Akronym aus TMAP for SAP steht für elf Fokusbereiche, die beim Testen von SAP besondere Aufmerksamkeit brauchen:

• Processes: Im SAP-Test zählt vor allem das Ergebnis der Geschäftsprozesse. Es wird verifiziert und validiert, auch dort, wo die Prozesse über SAP hinaus in andere Systeme reichen.
• Reports: Alles, was das Unternehmen verlässt, muss stimmen. Geprüft werden der Inhalt und ein lesbares Layout.
• Authorizations: Einkauf, Produktion, Personal, Vertrieb und Buchhaltung arbeiten mit unterschiedlichen Rollen. Die Berechtigungen müssen sensible Daten wie Personal- oder Finanzdaten abschirmen und bestimmte Aktionen den Berechtigten vorbehalten.
• Configuration: Über das Customizing werden Geschäftsprozesse, Organisationsstruktur, Stammdaten und unternehmensspezifische Parameter eingestellt. Wer testet, muss wissen, welches Verhalten damit beabsichtigt ist.
• Transports: Änderungen wandern per Transport von der Entwicklung über Test- und Akzeptanzsystem in die Produktion. Reihenfolge, Abhängigkeiten zwischen Objekten und die Möglichkeit zum Zurückrollen gehören in den Test. Ein fehlerhafter Transport kann ernste Folgen haben.
• Interfaces: Schnittstellen zu Nicht-SAP-Systemen brauchen Integrationstests, funktional und nicht-funktional, also auch für Verbindung, Performance und Security.
• Conversions: Daten aus Altsystemen müssen bereinigt, vollständig und einem Verantwortlichen zugeordnet sein. Früh prüfen, ob die neuen Prozesse mit den konvertierten Daten zurechtkommen.
• Enhancements: Eigene ABAP-Entwicklungen wie Z-Transaktionen und User Exits sind neuer Code, der noch nirgends gelaufen ist. Sie brauchen besondere Aufmerksamkeit und mehr Testaufwand.
• Screens: SAP-Masken lassen sich stark anpassen. Der Test prüft, ob sie die Arbeitsabläufe der Anwender effizient unterstützen.
• User Experience: Wie erleben die Anwender das System, etwa in SAP GUI oder Fiori? Das ist teils subjektiv, entscheidet aber mit darüber, ob die Lösung angenommen wird.
• Platform: Ob SAP in der Cloud, on-premises oder in einer Mischform läuft und welche Nicht-SAP-Systeme angebunden sind, prägt die Teststrategie mit.

Nicht jede Änderung berührt alle elf Bereiche. Die Checkliste zeigt schnell, welche betroffen sind, und sorgt dafür, dass keiner vergessen wird.

Wie läuft der Testprozess in SAP-Projekten ab?

In SAP-Projekten sind meist vier Testarten relevant, passend zur SAP-Methodik Activate: Unit-Test, Systemintegrationstest (SIT), Abnahmetest durch die Anwender (UAT) und Regressionstest. Unit-Tests sind Sache der Entwickler. Die Fachanwender steigen vor allem im UAT ein, manchmal schon im SIT.

Der SIT prüft die gesamte Anwendung samt ihrer Schnittstellen zu externen Systemen, mit Schwerpunkt auf der ein- und ausgehenden Kommunikation. Große Programme planen mehrere SIT-Zyklen und verteilen die Risikoklassen darauf. Läuft ein Happy Flow sauber durch, wird er Kandidat für die Regressionssuite und für die Automatisierung. Diese Suite wächst mit jedem Zyklus.

Im UAT prüfen die künftigen Anwender oder jemand in ihrem Auftrag in einer möglichst produktionsnahen Umgebung, ob das System ihre tägliche Arbeit unterstützt. Der Blick wandert zu End-to-End-Szenarien: vertikal innerhalb einer Lösung oder eines Moduls, horizontal über SAP-Module, SAP-Systeme und Nicht-SAP-Systeme hinweg. Nach jeder Änderung zeigt ein Regressionstest, dass die Teile, die gleich bleiben sollten, weiter funktionieren. Weil er so oft läuft, wird er am besten automatisiert.

Quality Gates verbinden die Phasen. Vor dem UAT prüft so ein Gate zum Beispiel, ob Geschäftsrollen und Logins für die Tester zugeordnet sind, die Schnittstellen bereitstehen, die Testumgebung aufgesetzt und mit den richtigen Testdaten gefüllt ist und Entwickler verfügbar sind, um Fehler zu beheben.

Wie richtet man eine SAP-Testumgebung ein?

Eine SAP-Testumgebung ist ein eigenes System in der Landschaft zwischen Entwicklung und Produktion. Änderungen kommen per Transport entlang der Kette Entwicklung, Test, Akzeptanz, Produktion dort an (DTAP). Diese Trennung ist die erste Regel. Die Testumgebung muss abgesichert und von der Produktion getrennt sein, damit keine sensiblen Daten abfließen und niemand Zugriff bekommt, der ihn nicht haben soll.

Die zweite Regel betrifft die Außenwelt. Einstellungen in der Testumgebung müssen ausgehende Kommunikation blockieren, damit keine Testbestellung und keine Testrechnung je bei einem tatsächlichen Kunden oder Lieferanten landet. Bei so vielen Schnittstellen zu Geschäftspartnern wird das leicht übersehen.

Danach kommt das Befüllen. Eine Kopie der Produktionsdaten in ein Testsystem zu ziehen, dauert lange. In der Zeit steht die Umgebung nicht zur Verfügung, und danach braucht das Testsystem dieselbe Kapazität wie die Produktionslandschaft. Performancetests haben das umgekehrte Problem. Sie gehören in eine produktionsnahe Umgebung, laufen aber oft auf Systemen mit weniger Kapazität. Die Ergebnisse sind dann nie ganz genau.

Testautomatisierung stellt eigene Anforderungen: eine stabile Umgebung, Zugriffsrechte für das Werkzeug und die Leute, die es bedienen, und ein SAP, das für Scripting freigeschaltet ist.

Testdatenmanagement in SAP-Projekten

Eine der größten Hürden im SAP-Testing sind die Testdaten. SAP verarbeitet die Kerndaten des Unternehmens, und die Stammdaten bestimmen, wie sich das System verhält. Aussagekräftige Tests brauchen deshalb relevante, realistische und datenschutzkonforme Testdaten. TMAP for SAP ordnet sie in fünf Datenklassen, die aufeinander aufbauen:

Für die Praxis heißt das:

• So klein wie möglich, so realistisch wie nötig. Ein guter Testdatenbestand ist realistisch, gültig und vielseitig und trotzdem der kleinstmögliche.
• Keine ungefilterte Kopie der Produktion. Eine Vollkopie bringt sensible Daten in Entwicklungs- und Testsysteme und muss nach DSGVO anonymisiert werden.
• Gezielt auswählen. Beim Subsetting werden nur die relevanten Daten nach Kriterien wie Zeitraum, Standort oder Typ herausgezogen. Das spart Speicher und macht den Test handhabbar.
• Sensible Daten schützen. Maskierung und rollenbasierte Zugriffe gehören dazu.
• Synthetische Daten mit Bedacht. Generierte Daten müssen die verschachtelten SAP-Strukturen konsistent abbilden, sonst entstehen Dubletten und Widersprüche.

Mit der nächsten Änderung anfangen

Strategie, Testprozess, Umgebung und Testdaten decken noch nicht alles ab. Performancetests und die Wahl der Testmanagement-Tools brauchen in SAP-Projekten jeweils eigene Überlegungen, Testautomatisierung über die Regressionssuite hinaus ebenso. Für den Anfang reicht es, PRACTICES UP neben die nächste Änderung zu legen und für jeden der elf Bereiche zu fragen: Ist er betroffen, und wer testet ihn? Denn in SAP laufen die Kernprozesse. Ein Fehler landet dort nicht in einer Nebenfunktion, sondern in Bestellungen, Rechnungen und Buchungen.

Häufig gestellte Fragen

Wie sieht eine gute SAP-Teststrategie aus?

Sie beginnt bei den Geschäftsprozessen und deren Ergebnis. TMAP for SAP leitet die Strategie aus der Checkliste PRACTICES UP, der Testbasis und einer SAP-Qualitätsrisikoanalyse ab. Die Risikoklasse jedes Prozesses legt fest, wie gründlich und in welcher Reihenfolge er getestet wird. Auch die Projektart, also Einführung, Rollout oder Upgrade, prägt die Strategie.

Was ist beim Testen von SAP anders als in normalen Softwareprojekten?

SAP kommt als weitgehend fertiges ERP-System ins Unternehmen. Projekte ändern deshalb mehr Konfiguration, Workflows, Daten und Berechtigungen als Code. Klassische Unit-Tests verlieren an Gewicht, Prozessprüfungen, Schnittstellentests, Abnahmetests und End-to-End-Tests gewinnen. Dazu kommen Transporte durch die Systemlandschaft und Eigenentwicklungen in ABAP, die eigene Tests brauchen.

Was gehört zum SAP-Testmanagement?

Dazu gehören eine Teststrategie, die auf einer Qualitätsrisikoanalyse beruht, und ein Testplan, der daraus Aktivitäten und Zeitplan macht. Kritische Prozesse kommen zuerst, verteilt auf mehrere Zyklen des Systemintegrationstests. Quality Gates zwischen den Phasen prüfen etwa, ob Testumgebung, Testdaten, Rollen und Schnittstellen bereitstehen, bevor der Abnahmetest beginnt.

Lässt sich SAP-Testing automatisieren?

Ja, vor allem der Regressionstest, weil er nach jeder Änderung läuft. Happy Flows, die im Systemintegrationstest bestanden haben, wandern in die Regressionssuite und von dort in die Automatisierung. Voraussetzung sind eine stabile Testumgebung, Zugriffsrechte für Werkzeug und Tester und ein SAP, das für Scripting freigeschaltet ist.