In diesem Blogartikel widmen wir uns der Frage, wie eine Qualitätssicherung bei einer SAP Einführung oder einer S/4 HANA Migration stattfinden kann. Ziel ist, das Verständnis rund um die Testaktivitäten aufzubauen, damit am Ende eines jeden SAP Vorhabens eine reibungslose Produktivschaltung gewährleistet werden kann.
Nicht selten wird mit SAP Projekten der Begriff «Komplexität» verbunden, die Königsdisziplin der Softwareeinführungen. Werden die Testaktivitäten innerhalb eines SAP Vorhabens geplant, ist ebenso eine gewisse Unsicherheit bezüglich der Testinhalte vorhanden, da die SAP Funktionalität, sprich der SAP Standard, bereits vom Hersteller getestet ausgeliefert wird. Vor jedem Release wird also von der SAP eine Testsession, der sogenannte SAP Beta-Test, mit verschiedenen SAP Partnern geplant. In dieser Testsession werden von der SAP vordefinierte Testfälle zur Verfügung gestellt und durch Partner geprüft, bevor ein Release freigegeben wird.
Unabhängig davon, ob es sich nun um eine SAP Neuimplementierung oder eine Migration auf S/4 HANA handelt, bleiben daher die folgenden Fragen meist unbeantwortet:
- Wann soll ich testen und was muss getestet werden?
- Wie sollen meine Tests strukturiert und aufgebaut werden?
- Welche SAP Tools stehen für eine Testautomatisierung zur Verfügung?
All diejenigen, die gerade vor einer SAP Einführung oder einer Migration auf S/4 HANA stehen, haben trotz geplanter Testaktivitäten Bedenken. Bedenken, dass der erwartete Big Bang aufgrund einer mangelnden Qualitätssicherung nicht wie geplant stattfindet, sondern in einem wirtschaftlichen Desaster endet und das Mysterium SAP in Flammen aufgeht.
(Quelle: https://www.pexels.com)
Aus diesem Grund muss im Idealfall das Thema «Software Testing» vor einem SAP Vorhaben auf die Agenda gesetzt werden, damit dieses nicht in Vergessenheit gerät. Zu einem späteren Zeitpunkt ist dies zwar möglich, allerdings kann es zu Engpässen in der Ressourcenplanung und/oder in der Projektlaufzeit führen und damit zu Verteuerung des Projektes.
Wann soll ich testen und was muss getestet werden?
Meine Erfahrungen haben gezeigt, dass in vielen Firmen kein Testprozess vorhanden ist oder sich im Aufbau befindet. Das führt oftmals dazu, dass ein systematisches Vorgehen für das Testen von Software fehlt und meist erst am Ende der Realisierungsphase entschieden wird, welche Funktionen der Software überprüft werden sollen. Redundante Tests und unsystematische Stichproben sind die Folge. Die Zehnerregel der Fehlerkosten besagt, dass die Kosten zur Fehlerbehebung überproportional ansteigen, je später Fehler im Software Development LifeCycle entdeckt und behoben werden. Zur Verdeutlichung kann ein einfaches Beispiel der rule-of-ten genannt werden: Die Kosten der Fehlerbehebung steigen um den Faktor 10, wenn ein Softwarefehler erst in der Realisierungsphase korrigiert wird anstatt in der Analyse und Planungsphase, da der Fehler bereits implementiert wurde und eventuell das Konzept angepasst werden muss. Dieses Beispiel zeigt, dass Software Testing nicht nur die Erstellung und Durchführung von Tests beinhaltet, sonders ebenfalls die Prüfung und Sicherstellung, ob alle Anforderungen fachlich sowie technisch korrekt umgesetzt werden. Dieses Ziel kann durch ein Review der geplanten SAP Anforderungen erreicht werden. Mögliche, zu prüfende Qualitätskriterien können sein:
- Vollständigkeit
- Inhaltliche Qualität
- Widerspruchsfreiheit
- Verständlichkeit
- Durchgängigkeit
- Dokumentationsformat und -struktur
- Prüfbarkeit / Testbarkeit
Die aufgeführten Qualitätskriterien werden messbar und testbar als Abnahmekriterien in den Anforderungen hinterlegt.
Es geht also nicht nur darum, die fehlerfreie Lauffähigkeit einer Software sicherzustellen, um ein SAP Projekt erfolgreich umzusetzen. Vielmehr ist darauf zu achten, dass der Testprozess im gesamten Software Development LifeCycle frühestmöglich integriert wird.
Die folgende Grafik zeigt wie ein Test LifeCycle für SAP Projekte jeglicher Art im gesamten Software Development LifeCycle aufgebaut und eingeführt werden kann. Dieser bewegt sich idealerweise parallel zum eigentlichen Entwicklungsprozess.
Nun können wir uns der Frage widmen, welche Testinhalte im Detail zu überprüfen sind. Wie bereits Eingangs erwähnt, wird der SAP Standard vor einem jeden Release von der SAP sowie von SAP Partnern getestet. Worauf ist nun der Fokus zu legen, wenn die Testphasen für eine Neuimplementierung bzw. einer Migration geplant werden?
Bei SAP Projekten soll das Hauptaugenmerk auf den kundenspezifischen Anpassungen bzw. auf Eigenentwicklungen liegen. Diese Eigenentwicklungen, die sogenannten Gaps, sowie alle kritischen Programmteile werden bereits in der Testplanung, spätestens jedoch in der Analyse & Planungsphase identifiziert, damit diese zu Beginn der Testfallerstellung bekannt und entsprechend priorisiert werden können. Der SAP Standard sollte allerdings auch in den Tests berücksichtigt werden, vor allem bei Integrations- und Schnittstellentests bzw. bei E2E-Tests. Bei der Vielzahl an Variationen innerhalb des SAP Systems können hier ebenfalls Fehler vorhanden sein, die eine Produktivsetzung gefährden würden.
Besonderheiten bei einer S/4 HANA Migration
Befinden wir uns gerade vor oder in einer S/4 HANA Migration, gibt es weitere Punkte in Bezug auf den Testinhalt zu beachten:
- Mit SAP Fiori sind über 300 Rollen verfügbar, die auf allen Endgeräten geprüft werden müssen.
- Besonders bei einer Migration nach dem Brownfield- oder einem Hybrid-Ansatz sollte die Testausführung zum einen mit den migrierten Daten aus einem Legacy-System und zum anderen mit den im regulären Stammdatenpflegeprozess des S/4 HANAs angelegten Daten stattfinden. Anschliessend findet ein Abgleich der Daten statt, im Idealfall verhalten sich alle Prozesse identisch.
- Speziell im S/4 HANA gilt es Performance-Engpässe zu vermeiden, indem kritische Programmteile identifiziert werden und der Fokus auf solche bei den Tests gelegt wird.
- S/4 HANA-basierte BI-Berichte müssen verifiziert und deren Funktionsfähigkeit sichergestellt werden.
Die folgende Grafik soll diese Besonderheiten bei einer S/4 HANA Migration verdeutlichen:
Wie sollen meine Tests strukturiert und aufgebaut werden?
SAP ist ein komplexes System mit endlosen Variationen. Es ist weder machbar noch kosteneffektiv, alle möglichen Variationen sowie Kombinationen von Testparametereingaben zu prüfen. Dementsprechend muss die Anzahl der Testfälle reduziert werden, ohne jedoch die Abdeckung zu beeinträchtigen. Aus diesem Grund ist für die Struktur und den Aufbau der SAP Tests die Wahl einer richtigen Strategie extrem wichtig.
Um einen effektiven SAP Testfall zu erstellen, sind folgende Punkte zu berücksichtigen:
- SAP Rolle bestimmen, die zur Ausführung des Testfalls benötigt wird
- SAP Transaktion identifizieren, die für den Testfall ausgeführt werden muss
- Vorbedingungen, die für die Testausführung erforderlich sind
- Erstellung von positiven sowie negativen Testszenarien
- Beschreibung der Testidee und die Erwartung an das Ergebnis
- Benötigte Testdaten festlegen
- Detaillierte Testschritte erfassen (inkl. erwartetes Ergebnis)
Weiterhin werden alle kritischen Schnittstellen bestimmt und ihre Konnektivität mit entsprechenden Testsystemen hergestellt. Hierbei werden alle Geschäftsszenarien identifiziert, die von der Schnittstelle verarbeitet werden. Zu überprüfen sind ebenfalls die ausgehenden und eingehenden Schnittstellen / Telegramme, ob diese die richtigen Schritte im Zielsystem ausführt.
Falls nicht in den Testfällen beschrieben, werden während der Testausführung in SAP Projekten die folgenden Systemkontrollen durchgeführt:
- Kontrolle auf Dumps
- Kontrolle auf Verbuchungsabbrüche
- Kontrolle des System- und Applikationslogs
- Kontrolle von Nachrichten-Queues im System für RFC-Aufrufe
- Kontrolle hängender RFC-Calls
Welche SAP Tools stehen für eine Testautomatisierung zur Verfügung?
eCATT (extended Computer Aided Test Tool) ist die SAP eigene Entwicklung eines Werkzeugs zur Testautomatisierung. Dieses Werkzeug wird verwendet, um funktionale Tests für SAP zu erstellen und auszuführen. Das Hauptziel ist das automatisierte Testen von SAP Geschäftsprozessen. Mit dem Transaktionscode SECATT wird das eCATT-Einstiegsbild aufgerufen. Nützliche Funktionen sind unter anderem:
- Testen von Transaktionen, Szenarien und Reports
- Testen von entfernten Systemen
- Aufrufen von BAPIs und FuBas
- Prüfen von Berechtigungen
- Testen von Updates
Weiterhin liefert die SAP für Kunden in der SAP S/4 HANA Cloud nicht nur detaillierte Testskripte für Geschäftsprozesse, sondern auch ein Testautomatisierungstool mit vorgefertigten Testprozessen (Testautomaten). Die verfügbaren Testautomaten sind für die meisten Geschäftsprozesse in der SAP S/4 HANA Cloud verfügbar und auch für Benutzer gedacht, die keine Entwicklerkenntnisse haben. Zu erreichen sind diese Testautomaten in der App «Testprozesse verwalten» im SAP S/4 HANA Cloud-System.
Wie mystisch ist also SAP Testing?
SAP ist eine sehr komplexe Software, die abzubildenden Prozesse werden immer kritischer und SAP hat in der Tat ein paar Besonderheiten, die in diesem Artikel behandelt wurden. Allerdings kann ein jedes SAP Projekt qualitätsgesichert werden, um das Risiko bei einer Einführung bzw. Migration zu minimieren. Hierfür benötigt es unter anderem:
- den richtigen Testprozess
- die passende Teststrategie
- geeignete Testtechniken
- strukturierte Vorgehensweisen
- das Durchführen einer Risikoanalyse
Ich hoffe, dass ich durch diesen Artikel einen Überblick über das SAP Testing geben konnte. Das Mysterium SAP Testing liegt nun offen, mit bekannten (Test-) Vorgehensweisen kann ein solches Projekt beherrscht und zum Erfolg geführt werden.
Wusstest du schon…
…dass SwissQ über 15 Jahre erfolgreich im Bereich Testing ist? Gerne überzeugen wir Dich mit unserer SAP Testing Expertise und stehen jederzeit für ein Beratungsgespräch zur Verfügung. https://swissq.it/testing/
When you ask, the answer will be given!