Erfahren Sie, warum herkömmliche Ansätze für SAP Integrationstests oft an ihre Grenzen stoßen und wie Projektleiter diese Herausforderungen erfolgreich bewältigen können. Wir beleuchten die Top 3 Herausforderungen, von der komplexen Systemlandschaft bis zum Testdatenmanagement.
Entdecken Sie, wie unser neuer Ansatz nicht nur die Last von den Key-Usern nimmt, sondern auch zu einem effizienteren und qualitativ hochwertigeren SAP-Integrationstest führt.
Mit praxisnahen Einblicken und einer Erfolgsgeschichte aus einer der größten SAP S/4 HANA-Umstellungen erfahren Sie, wie dieser Ansatz zu 100 % Testabdeckung, Zeitersparnis und einer transparenten Entscheidungsvorlage für das Board führt.
Buchen Sie jetzt Ihr kostenloses Beratungsgespräch, um sicherzustellen, dass Ihr SAP-Integrationstest ein voller Erfolg wird.
Table of Contents
Bevor wir den herkömmlichen Ansatz mit dem neuen vergleichen, wollen wir zunächst betrachten, wie SAP-Systemlandschaften im Allgemeinen aussehen und welche Testphasen in den meisten SAP-Integrationstests zur Anwendung kommen.
DIE ÜBLICHEN VERDÄCHTIGEN: DIESE SAP-SYSTEMLANDSCHAFT HAT SICH BEWÄHRT
Die meisten größeren Unternehmen und Organisationen bevorzugen eine 3-Systemlandschaft, um einen klaren und geordneten Entwicklungszyklus zu ermöglichen. Das Entwicklungs- (DEV)-System wird für die Erstellung und Anpassung von Programmen und Anwendungen verwendet, das Test- (Qualitäts- oder Q-) System dient für Integrationstests und Qualitätssicherung, und das Produktiv- (PROD)-System wird für den produktiven Betrieb genutzt.
DIESE TESTPHASEN SOLLTE MAN IM PROJEKTPLAN WIEDERFINDEN
Will man sicherstellen, dass nach dem SAP Releasewechsel alle Prozesse und die systemübergreifenden Schnittstellen funktionieren, sollten folgende Testarten fester Bestandteil des Projektes sein:
Unit Test (UT)
Der Unit Test konzentriert sich auf die Überprüfung einzelner Einheiten des Codes, wie Funktionen oder Module, um sicherzustellen, dass sie korrekt und unabhängig funktionieren. Er ist die grundlegendste Testphase und bezieht sich auf kleine Einheiten des Codes.
Integration Test (IT)
Der Integrationstest stellt sicher, dass die einzelnen Module miteinander interagieren und Daten korrekt zwischen ihnen fließen. Er überprüft die Integration von Komponenten und Funktionen. Dieser Test fokussiert sich auf die Integration von Modulen und deren reibungslose Zusammenarbeit. Häufig werden hier End-to-End-Tests durchgeführt.
SAP System Integration Test (SIT)
Der SIT erweitert den Integrationstest auf das gesamte SAP-System. Er stellt sicher, dass die verschiedenen SAP-Module und -Komponenten effektiv zusammenarbeiten. Der SIT ist spezifisch auf die Integration von SAP-Modulen ausgerichtet und bezieht sich auf das gesamte SAP-System. Hier finden dann die Schnittstellentests zu anderen Non-SAP-Systemen statt.
SAP User Acceptance Test (UAT)
Der UAT ist darauf ausgerichtet, sicherzustellen, dass das SAP-System den Geschäftsanforderungen der Endbenutzer entspricht und von ihnen akzeptiert wird. Er überprüft die Benutzerfreundlichkeit und -zufriedenheit. Der UAT ist die letzte Testphase vor der Produktivsetzung und stellt sicher, dass die Prozesse funktionieren und die Benutzer das System in ihrer realen Arbeitsumgebung akzeptieren können.
CHALLENGE ACCEPTED? NEHMEN SIE DIESE 3 HERAUSFORDERUNGEN AN?
Natürlich gibt es deutlich mehr als 3 Herausforderungen in einem SAP-Integrationstest, aber die folgenden müssen optimal gelöst werden, und das ist gar nicht so einfach.
Komplexe Systemlandschaften
In vielen Unternehmen sind die SAP-Systemlandschaften äußerst komplex, bestehend aus verschiedenen Modulen und Schnittstellen zu anderen Systemen. Dies erschwert die Identifikation und Isolierung von Problemen während des Integrationstests.
In vielen Unternehmen sind die SAP-Systemlandschaften äußerst komplex, bestehend aus verschiedenen Modulen und Schnittstellen zu anderen Systemen. Dies erschwert die Identifikation und Isolierung von Problemen während des Integrationstests.
Auswirkungen: Fehler in einem Teil des Systems können unvorhergesehene Auswirkungen auf andere Bereiche haben, was zu Schwierigkeiten bei der Fehlerlokalisierung und -behebung führt.
Deswegen sollte im System Integrationstest (SIT) ein besonderes Augenmerk auf übergreifende Schnittstellentests gelegt werden!
Testdatenmanagement
Die Bereitstellung und Verwaltung von qualitativ hochwertigen Testdaten für den Integrationstest ist oft eine komplexe Aufgabe. Die Testdaten müssen nicht nur repräsentativ für die Produktionsumgebung sein, sondern auch vertraulich und anonymisiert, um Datenschutzbestimmungen zu erfüllen.
In den meisten Fällen werden die Integrationstests auf dem Qualitätssystem (Q-System) durchgeführt. Hier ist dann die Herausforderung, valide Testdaten auf dem Q-System zur Verfügung zu stellen. Üblicherweise wird das Produktivsystem dafür einmal auf das Q-System kopiert.
Die Frage ist nur, wann ist der beste Zeitpunkt dafür?
Zeitaufwand und Ressourcenmanagement
Integrationstests erfordern einen beträchtlichen Zeitaufwand und binden damit Ressourcen, insbesondere wenn es um die Koordination von verschiedenen Teams und die Vorbereitung der Testumgebung geht. Der Zeitpunkt des Integrationstests kann auch kritisch sein, da er häufig in den Entwicklungszyklus integriert werden muss.
Neben dem Testdatenmanagement die wichtigste Herausforderung.
Verzögerungen im Zeitplan können zu erhöhten Kosten führen und die pünktliche Bereitstellung von Systemverbesserungen oder neuen Funktionen behindern.
SAP BULL***T-BINGO: WIE OFT „KLINGELT“ ES BEI IHRER SAP-INTEGRATIONSTEST-UMSETZUNG?
Also mit anderen Worten, läuft es bei ihnen auch so, wie es bei allen anderen läuft? Lassen sie uns einmal prüfen, wie viel von den folgenden Themen, bei ihnen schon gesetzt sind, oder die sie so planen.
Die Experten*Innen für die Testfälle: Ihre KeyUser*Innen
In den über 25 Jahren, in denen ich SAP-Projekte begleite, wurden die Testfälle zu 80% von den Key-Usern erstellt, die restlichen 20% werden vom IT-Team des Unternehmens beigesteuert.
Üblicherweise ist der Start des Integrationstests damit verbunden, dass die Prozesse im SAP-System gecustomized sind.
Schaut man dann in den Projektplan, sind es dann bis zum nächsten Meilenstein ca. 4 Wochen. In dieser Zeit sollen alle Testfälle ausführlich beschrieben sein.
Können Sie hier ihr erstes Bingo Kästchen ankreuzen?
Wann können wir mit den KeyUser*Innen einen Termin vereinbaren?
Und da beginnen sie, ihre Probleme. Denn wer ist üblicherweise der/die Key-User*In aus der Fachabteilung? Der oder die mit dem besten Überblick über die Prozesse innerhalb der Abteilung, logisch.
Und wer hat nie Zeit, sich um diese Dinge zu kümmern, weil er anderer Stelle im Projekt benötigt wird? Genau, die Key-User*Innen.
Ich denke, hier ist das nächste Bingo Kästchen fällig
Reden ist Silber, Schweigen ist Gold. Haben sie eigentlich ihre Mitarbeiter eingebunden?
Natürlich haben sie das, oder? Sie würden doch nicht auf die Erfahrung ihrer Mitarbeiter beim Aufsetzen der Testprozesse verzichten? Das sind ja diejenigen, die den eigenen Testprozess am besten kennen.
Und die nach dem SAP Integrationstest die Prozesse dann wieder mit Freude in der neuen Umgebung anwenden werden.
Ach, die haben auch keine Zeit? Ah ja, das Tagesgeschäft, es muss ja laufen, auch klar. Nein, dann geht es mit den eigenen Mitarbeitern natürlich nicht, dann machen es besser die KeyUser*Innen.
Ich denke, hier könnte das nächste Bingo Kästchen angekreuzt werden
Haben ihre Testtickets auch DEN Expertenstatus?
Und so ist es dann natürlich nicht verwunderlich, dass die Testfälle häufig mit der heißen Nadel gestrickt werden, und einen echten Expertenstatus haben.
Aber Vorsicht, Expertenstatus heißt in diesem Fall, dass nur der Experte aufgrund der Stichworte im Testfall, den Testfall auch bearbeiten kann. Dritte haben in den meisten Fälle keine Chance, die Tests durchzuführen.
Hier ein paar Beispiele für Experten Test Tickets:
Das rächt sich nach hinten raus, denn die Endanwender, die diese Tickets testen sollen, müssen immer wieder bei den Key-Userinnen und Key-Usern nachfragen, was genau damit gemeint gewesen ist.
Hier haben wir wieder den typischen Sägezahneffekt, der dazu führt, dass die Bearbeitung der Tickets deutlich zeitaufwändiger ist, als wenn alles gleich sauber dokumentiert ist.
Und die IT? Richtig, auch die steuert ja noch Testfälle dabei. Seien wir ehrlich, wir reden hier häufig über Programmierer, und deren beliebteste Disziplin ist nicht, den Code zu dokumentieren, respektiv den Testfall sauber zu beschreiben.
Auch hier kann man dann nur rudimentär beschriebene Testfälle erwarten, auch hier sind Rückfragen der Endanwender bei den Tests vorprogrammiert.
Wie sieht es mit einem Bingo Kästchen bei den Testtickets mit Expertenstatus aus?
Der Ärger mit den Stammdaten für die Testfälle
Die Erstellung einer Kopie des Produktivsystems für das Qualitäts- bzw. Testsystem sowie die darauffolgende Anonymisierung der produktiven Daten ist ein zeitaufwendiger Prozess. In der Regel wird dies nur einmal oder höchstens zweimal pro Jahr durchgeführt. Diese Vorgehensweise stellt die Tester vor eine Herausforderung, da sie bevorzugt mit aktuellen Daten arbeiten würden. Dies gestaltet sich jedoch als nicht trivial und erfordert erheblichen Aufwand.
Hier kann man aber festhalten, dass in den meisten SAP Releasewechseln, eine Systemkopie vor den stattfindenden Integrationstests durchgeführt.
Das hat aber noch nicht zur Folge, dass die Testtickets einfach getestet werden können. In jedem Fall werden Stammdaten benötigt, wie zum Beispiel die richtigen Materialnummern, oder die richtige Verkaufsbelgart, oder der richtige Lieferant, heute Business Partner genannt. Und sie können es sich bereits denken, wer von den Key-User*Innen Zeit hat, diese Stammdaten zu definieren? Sie fehlen zu fast 100% in den Testtickets, das führt natürlich wieder zu einem erheblichen Mehraufwand für den Tester
Müssen sie hier auch wieder ein Kreuz für das Bingo Kästchen: „Fehlende Stammdaten“ setzen?
Zusammenarbeit bei der Bearbeitung der Testfälle
In den meisten Fällen werden entweder Excel oder Google Sheets zum Erstellen der Testfälle genutzt. Die Zusammenarbeit findet per E-Mail und über SharePoint, Google Drive oder andere Cloud Plattformen statt.
Nun ja, das geht schon einigermaßen, aber ein integrierter Ansatz, in dem Tester und IT effizient zusammenarbeiten können, sieht sicher anders aus.
Dieses Bingo Kästchen ist etwas differenzierter zu betrachten. Setzen sie hier einen Haken, wenn sie ihre Testfälle ohne Workflow abarbeiten.
Und zukünftig testen wir automatisiert
Das ist natürlich die Königsdisziplin, das i-Tüpfelchen, die Kirsche auf der Torte. Das will jeder, Ehrensache. Aber die Realität sieht anders aus. Bis die Testfälle den Reifegrad der Automatisierung erreicht haben, muss noch sehr viel mehr gemacht werden. Das ist so Zeitaufwendig, das kostet so viel Geld, da müssen wir ja alles noch mal machen, dafür können wir keine Ressourcen bereitstellen.
Finden Sie sich hier wieder? Dann setzen sie hier das Kreuz im nächsten Bingo Kästchen.
Doch die Wahrheit sieht ganz anders aus: Mit dem richtigen Ansatz, können sie, ohne das Tagesgeschäft zu beeinflussen, ihre Testfälle so aufsetzen, dass sie später problemlos automatisiert werden können.
Und wie findet das Reporting in solchen Projekten statt?
Wie schon bei der Zusammenarbeit der Testfälle beschrieben, liegen die Testdaten häufig auf Cloud Plattformen und von dort müssen sie erst für das Reporting in Excel oder Google Sheet aufbereitet werden, damit sie PowerPoint oder Google Presentation gezeigt werden können.
Im Klartext bedeutet das: Excel bereitet die Daten unter den gewünschten Aspekten auf und das Ergebnis wird in PowerPoint „wunschgemäß“ presentiert. Die Datengrundlage wird häufig nicht hinterfragt und in den SteerCo Meetings sieht alles sehr vielversprechend aus.
Wenn dann aber ein Chief Executive Officer fragt, ob auf Basis der Testergebnisse einer Produktivsetzung nichts mehr im Wege steht, dann kommt erst vielleicht kein betretenes Schweigen vom Projektleiter, aber zumindest die Aussage, dass muss noch einmal verifiziert werden.
Machen sie hier ein Kreuz im Bingo Kästchen für das Excel Reporting
SCHREITEN WIR ZUR AUSWERTUNG
Dies Kreuze konnten gemacht werden:
- KeyUserInnen erfassen die Testfälle
- Keine Verfügbarkeit der KeyUserInnen
- Mitarbeiter*Innen erfassen keine Testfälle
- Testtickets haben den Expertenstatus
- Testtickets ohne Stammdaten
- Testtickets ohne Workflow
- Keine Testautomatisierung möglich
- Das Reporting finden in Excel statt
Kreuze 1 bis 8
Herzlichen Glückwunsch, sie befinden sich in guter Gesellschaft 😊. So machen es fast alle!
Ihr SAP Integrationstest besticht durch:
- Keine ausreichende Verfügbarkeit der Key-User*Innen
- Die Mitarbeiter werden nicht mit einbezogen
- Keine saubere Beschreibung der Testfälle
- Schlechte Testabdeckung
- Technik-Stress: Ineffiziente Zusammenarbeit zwischen den Testern und der IT zum Lösen der gefundenen Fehler
- Wiederverwendbarkeit ist eher nicht gegeben
- Keine valide Entscheidungsgrundlage für das Steer Co, ob man den Go-live durchführen soll
- Sehr zeitaufwendig, da hoher Betreuungsaufwand durch Key User und IT notwendig
- Keine Automatisierung möglich
Kreuze 4 bis 8
Immerhin haben sie erkannt, dass ihr Mitarbeiter, ihr wertvollstes Kapital sind. Das ist schon mal eine sehr gute Erkenntnis und damit ist ihr SAP Integrationstest ausbaufähig
Ihr SAP Integrationstest besticht durch:
- Schlechte Testabdeckung à Dieser Punkt bleibt, da in den meisten Fällen keine richtige Testabdeckung gegeben ist
- Technik-Stress: Ineffiziente Zusammenarbeit zwischen den Testern und der IT zum Lösen der gefundenen Fehler
- Wiederverwendbarkeit ist eher nicht gegeben
- Keine valide Entscheidungsgrundlage für das Steer Co, ob man den Go-live durchführen soll
- Sehr zeitaufwendig, da hoher Betreuungsaufwand durch Key User und IT notwendig
- Keine Automatisierung möglich
Nicht ein einziges Kreuz?
Sie müssen bereits ein Kunde von uns sein 😊
WARUM 0 TREFFER IM SAP BULL***T-BINGO NICHT DIE NIETE, SONDERN DER HAUPTGEWINN SIND
Wie bereits mehrfach erwähnt, bin ich seit über 25 Jahren in SAP-Projekten und SAP Integrationtests unterwegs. Ich habe als Key-User in SAP-Projekten angefangen und genau diese Arbeit gemacht.
Warum? Weil auch die Mitarbeiter keine Zeit hatten, diese Testfälle vernünftig aufzusetzen. Und damit war und ist der/die Key-User*In die beste Wahl für das Projekt
Das ist also der eigentliche Grund warum der Key-User*Innen Ansatz heute auch noch sehr häufig angewendet wird, oder sie 8 Kästchen angekreuzt haben.
Versetzen sie ihre Mitarbeiter in die Lage die Testfälle aufzusetzen
Keiner kennt die Prozesse, die getestet werden sollen, besser als die, die sie anwenden. Und keiner wird ihnen eine bessere Testabdeckung ermögliche als ihre Mitarbeiter.
Und diese sind darüber hinaus auch dankbar, dass sie in das Projekt mit einbezogen werden.
Verteilen sie die Last von den KeyUsern*Innen auf ihre Mitarbeiter, damit die KeyUser*Innen konzeptionell an der Optimierung ihrer Prozesse arbeiten können.
Innerhalb kürzester Zeit bekommen sie, mit den notwendigen Informationsveranstaltungen, eine komplette Dokumentation aller Prozesse, bei gleichzeitiger Entlastung der KeyUser*Innen.
Auch die IT freut sich, da sie die Testfälle nicht mehr aufsetzen muss, das macht sie gleich beliebter bei den Kollegen aus der IT, kein Spruch!
Allerdings muss, dass Zusammenspiel zwischen IT und Fachbereich besser werden. Man muss sich heutzutage nicht mehr in einen Raum setzen, um die Testfälle durchzugehen und mit den Kollegen aus der IT besprechen.
Mittlerweile gibt es wirklich sehr gute Tools, die ein Zusammenspiel zwischen dem Fachbereich und der den SAP Teams signifikant verbessern. Ich rede hier nicht von Liebe, aber wir können wirklich dankbar sein, dass die Integrationstests durch diese Tools sehr viel einfacher durchzuführen sind.
Durch diese Tools wird auch das Reporting nicht mehr zu Glaubensfrage, sondern fundiert auf echten Fakten, und diese kann man dann live in einem Steer Co Meeting präsentieren.
Das sind endlich echte Entscheidungsvorlagen, aus denen abgeleitet werden kann, ob ein Go-live möglich ist oder nicht.
DIE NULL-KREUZE SUCCESS STORY
Nun, diesen Ansatz habe ich selbst in einem der größten SAP S/4 HANA Umstellungen konzipiert und umgesetzt. Insgesamt wurde ein weltweit operierendes Unternehmen mit mehr 12.000 Mitarbeitern auf SAP S/4 HANA umgestellt.
Es gab insgesamt 3 Unternehmensbereiche, von denen ich bei einem Unternehmensbereich kurzfristig die Verantwortung für das Integrationstests übernommen hatte.
Wir haben innerhalb eines Monats alle Prozesse durch die Mitarbeiter erstellen lassen, diese dann in ein Kollaborationstool hochgeladen.
Die Key User haben minimal bei der Erstellung der Testfälle unterstütz und selbst keine Tests durchgeführt, es sei denn, sie haben ihre eigenen Prozesse testen müssen.
Der Teilbereich, den ich in diesem Projekt verantwortet habe, hat sowohl im Integrationstest, als auch im User Acceptance Test alle Testfälle zu 100% durchgetestet.
Diese Testfälle stehen dem Unternehmen seit der SAP S/4 HANA Umstellung zur Verfügung und werden nun schon zum vierten Mal einmal pro Jahr, aufgrund eines SAP S/4 HANA notwendigen Updates, zum Integrationstest wiederverwendet.
Wenn sie auch wissen wollen, wie sicherstellen können, dass ihr SAP Integrationtest ein voller Erfolg wird, dann buchen sie jetzt ein kostenloses Beratungsgespräch mit mir und ich zeige ihnen, wie die Umsetzung des Null-Kreuze-Ansatzes auch bei ihnen zum Erfolg führt.
Sie bekommen:
- 100% Entscheidungsvorlage für das Board, ob der Releasewechsel durchgeführt werden kann, oder nicht.
- 70% Zeitersparnis durch Mitarbeitererhebung & Evaluierung der relevanten Testsituationen.
- Transparenter und standardisierter Testprozess.
- Inklusive Dokumentation aller Geschäftsprozesse.
- 100% Wiederverwendbarkeit für den nächsten Integrationstest
- Integrationstest mit JIRA und Confluence von Atlassian.
- Abbruchquote von 0%.
- 100% unserer Kunden können sich nicht mehr vorstellen, ohne uns einen Releasewechsel vorzunehmen.
