Da in den Unternehmen in allen Geschäftsbereichen immer drängender nach schnelleren Releases verlangt wird, sind ein oder zwei Updates pro Jahr nicht mehr ausreichend. Der Wechsel zu einer agilen Softwareentwicklung, insbesondere für SAP, ermöglicht mehr Innovation und eine schnellere Umsetzung von Änderungen, macht aber auch umfangreiche Tests notwendig, damit auch alle Änderungen wie gewünscht funktionieren. Das Testen einer kleinen Änderung mag dabei problemlos sein, aber wie wirkt sie sich auf die gesamte Produktionsumgebung aus?
Wir alle wissen, dass manuelle SAP-Tests zeitaufwendig und fehleranfällig sind und dass umfangreiche Regressionstests in SAP für jede einzelne Änderung nicht praktikabel sind. Bis ein manueller SAP-Test abgeschlossen ist, können Wochen oder sogar Monate vergehen, was den Vorteil eines agilen Ansatzes zunichtemacht und den Geschäftsstrategien zuwiderläuft. Durch den Einsatz eines effektiveren SAP-Testmodells eröffnen sich jedoch neue Möglichkeiten, um Ihr Unternehmen vor fehlerhaften Releases zu schützen.
1. Die Übernahme von SAP-Testautomatisierung.
Um sich vor Programmierfehlern, Inkompatibilitäten und Sicherheitslücken zu schützen, wenden sich viele Unternehmen der Robotic Test Automation zu. Auf diese Weise können Änderungen zu jeder Zeit getestet werden, ohne auf den Abschluss manueller Tests warten zu müssen oder sich zu sorgen, dass etwas Wichtiges vergessen wurde. So sollten moderne, agile IT-Abteilungen heutzutage testen.
2. Testen Sie mehr als das Offensichtliche.
Es ist wirklich verlockend, für Tests nur die häufig verwendeten Geschäftsprozesse einzubeziehen, insbesondere bei manuellen SAP-Tests. Und weniger genutzte Prozesse werden gern vernachlässigt, um das nächste Software-Release rechtzeitig ausliefern zu können. Werden jedoch wenig genutzte Prozesse nicht getestet, ist es sehr wahrscheinlich, dass diese eines Tages zu schweren Fehlern im System führen. Im Gegensatz dazu stellt eine umfassende Robotic Test Automation sicher, dass auch diese Prozesse getestet werden, und zwar schneller, als es mit manuellen Tests möglich wäre.
3. Misstrauen Sie risikobasierten Testmethoden.
Der große Fehler bei risikobasierten Tests ist, dass nur solche Szenarien getestet werden, von denen man glaubt, dass sie hauptsächlich durch die technischen Änderungen eines Release betroffen sind. Dabei werden alle anderen möglichen Szenarien ignoriert und, wie beim Testen von nur offensichtlich betroffenen Prozessen, wird das Unternehmen dem Risiko ausgesetzt, dass nicht getestete Szenarien zu schweren Fehlern führen. So können zum Beispiel Stammdaten, die von den meisten risikobasierten Testprogrammen außer Acht gelassen werden, schon durch kleinste Fehler die in den Hauptprozessen verwendeten Logiken erheblich beeinträchtigen und das System schwer schädigen.
4. Testen Sie nicht nur an der Oberfläche.
Unternehmen nutzen SAP auf vielfältige Weise und das Beschränken von Tests auf die Benutzeroberfläche ist wie der Check der Tankanzeige am Auto anstelle einer echten Revision. Sie zeigt natürlich an, dass der Tank voll ist – aber was ist mit Öl, Reifendruck, Bremsen, Elektrik? Tests müssen auf jede Art „umfassend“ sein, bis hin zu sekundären Effekten auf andere Systeme und auf den Benutzer. Man kann unmöglich die Auswirkungen auf andere Schnittstellen innerhalb eines komplexen SAP-Systems einschätzen, ohne sie alle zu testen, insbesondere, wenn Geschäftsbereiche auf diese anderen Systeme angewiesen sind, um auf SAP-Daten für kritische Funktionen zugreifen zu können. Eine betroffene Schnittstelle, z. B mit Bezug zu einem CRM-System, kann das gesamte Tagesgeschäft zum Stillstand bringen.
5. SAP-Tests nach links verschieben.
„Testing left“ ist ein Konzept, das im Wesentlichen bedeutet, so früh und so oft wie möglich zu testen. Die Realität bei SAP sieht so aus, dass oft erst sehr spät innerhalb des Entwicklungszyklus getestet wird, da SAP als überaus komplex gilt und eine Vielzahl von Abhängigkeiten mit anderen Systemen besteht. In der Vergangenheit war es nur selten möglich, eine vollständige QA-Umgebung mit Testdaten einzusetzen, weil die dafür notwendige Testversion praktisch nie rechtzeitig zur Verfügung stand. Heute können für SAP-Regressionstests Service-Virtualisierungen eingesetzt werden, noch bevor für neuen Code eine QA erforderlich ist. Unternehmen können so die Testphase nach links verschieben – und früher und öfter testen, als es vorher möglich war.
6. Integration der Testphase in CI/CD-Workflows.
Sobald der Code fertig ist, muss der SAP-Test beginnen. Wenn ein Unternehmen zusätzlich zur Einführung von Regressionstests damit beginnt, Testphasen zu integrieren, die über die Benutzeroberfläche hinausgehen und weiter links im Software-Entwicklungszyklus stehen, sollten sie im bestehenden CI/CD-Workflow eingebunden werden. Der Gedanke hinter der Robotic Test Automation ist, Tests so einfach wie möglich zu machen. Und sind sie einmal fertig eingerichtet, ist es absolut sinnvoll, die Softwareentwicklung und die Tests so weit wie möglich in die CI/CD-Prozesse einzubinden.
Dank der Verfügbarkeit von Robotic Test Automation für SAP ist es möglich, Tests in jede Phase des Entwicklungsprozesses zu integrieren. Dies erleichtert die Umstellung auf DevOps für SAP, um den Geschäftsanforderungen besser gerecht zu werden.
Erfahren Sie mehr zu den 6 Schritten zu effektiven SAP-Tests und besuchen Sie unser Webinar oder fordern Sie eine Demo von Testimony an, und erfahren Sie, wie unsere DevOps-Tools Ihnen helfen, eine flexible SAP-Umgebung aufzubauen.
