Mit größeren Projekten als der Migration von SAP ECC auf S/4HANA haben es ERP-Teams in den Unternehmen derzeit wohl kaum zu tun. Sie erwartet ein kostspieliges und umfangreiches Unterfangen mit Projektlaufzeiten bis zu mehreren Jahren. Den Gesamtumfang schneidet man üblicherweise in kleinere handhabbare Teile und mehrere Fach-Streams arbeiten parallel an der Transformation. Ein begleitendes Testmanagement ist dabei obligatorisch. Allerdings wird gern vergessen, hier rechtzeitig das Business einzubeziehen. Ein Fehler, der sich teuer rächt.
S/4HANA eröffnet jedem SAP-Kunden die einmalige Gelegenheit, bisherige Geschäftsprozesse zu überdenken, sie zu verbessern oder völlig neu aufzusetzen. Anforderungen aus dem Business können und sollen in die neue Produktgeneration explizit einfließen. Die (Key) User starten also den „Requirement Trace“, mit anderen Worten sie formulieren ihre Geschäftsanforderung an eine bestimmte ERP-Funktion.
Anschließend nimmt die Umsetzung ihren Lauf: Ein Design wird aufgesetzt, die Entwicklung programmiert das Ganze in S/4HANA und am Ende funktioniert es. Ein Wunschtraum, denn die Realität ist wie immer viel komplizierter. Wenn am Ende die User Acceptance Tests anstehen, stellt sich oft heraus: Der initiale Gedanke des Business ist unterwegs verloren gegangen oder wurde zumindest stark verwässert.
Woran liegt´s? Schließlich wurden die altbewährten Testmethoden angewandt: Unit-, Integrations- und schließlich User Acceptance Tests. Die IT als Testinstanz ist allerdings zumeist recht weit entfernt von der ursprünglichen Anforderung. Sie prüft rein technische Sachverhalte und testet, ob das Design von der Entwicklung richtig umgesetzt wurde. Offen bleibt aber die Frage, wie sich die Anforderungen später konkret im Tool darstellen. Auch bei der Dokumentation vom Requirement bis hin zum Ergebnis mangelt es immer wieder an klaren Strukturen.
Testen muss agil werden
Testmanagement ist für eine erfolgreiche Migration unabdingbar. Es stellt sicher, dass alle Funktionen und Prozesse im neuen System ordnungsgemäß funktionieren und die Daten vollständig und korrekt migriert wurden. Das Testmanagement umfasst die Erstellung von Testplänen und -szenarien, die Durchführung von Tests, die Überwachung von Ergebnissen und das Nachverfolgen von Fehlerbehebungen.
„Wie geht man bei einer S/4HANA-Transformation mit dem Testen um? Agil oder Wasserfall? In beiden Fällen wird, ohne das Business frühzeitig mit einzubeziehen, eine Migration in time & budget quasi nicht haltbar sein. Hilfreich ist es zudem, Testläufe soweit als möglich zu automatisieren.“
– Alexander Schöberl, Senior Consultant Projektmanagement, SIRIUS Consulting
Traditionelle Wasserfallmethode oder agiles Vorgehen – diese beiden Paradigmen stehen auch beim Testen zur Auswahl. Die meisten Firmen entscheiden sich für einen hybriden Ansatz und orientieren sich dabei an der Entwicklung. Dort wird – obwohl die Umstellung auf S/4HANA durchaus auch per Wasserfall funktioniert – inzwischen zumeist agil gearbeitet, um den sich immer schneller ändernden Anforderungen des Marktes gerecht zu werden. Hybrid bedeutet: Bestimmte Abschnitte (normalerweise einen Teil des Designs und der Anforderungssammlung) werden per Wasserfall erarbeitet, anschließend geht es schnell in die agile Entwicklung über. So bleibt man flexibel und kann die Projektlaufzeit reduzieren. Wer agil entwickelt, sollte in der Konsequenz deshalb auch agil testen.
Erster Testdurchlauf sind stets die Unit Tests (auch Developer Tests genannt), bei denen man einzelne Arbeitspakete bzw. Funktionen prüft. Sie werden oft von der IT beauftragt, die durchführenden Personen sind aber nicht Teil derer. Ein Unit Test hat noch nichts mit dem Design zu tun, es handelt sich um eine rein syntaktisch-technische Prüfung des Codes. Zwei Stufen sollten bei S/4HANA-Transformationen durchlaufen werden: 1. „Raucht“ etwas ab („Smoke-Test“)?, 2. Sind alle Akzeptanzkriterien für ein Arbeitspaket erfüllt?
User-Anforderungen schon in die Integrationstests einbauen
Integrationstests befassen sich anschließend mit den designten Prozessen. Hier werden Integrationsbausteine aneinandergereiht und Testdaten durch den kompletten Prozess (bzw. den bereits entwickelten Teil davon) geschickt. So wird ermittelt, ob die Bausteine richtig zusammenspielen.
Genau an dieser Stelle versäumen es viele Unternehmen, das Business mit einzubeziehen. Dabei sollte es unbedingt bereits während der Designphase die Gelegenheit erhalten, das, was aus der Entwicklung kommt, auf seine Praxistauglichkeit hin zu prüfen. So sind frühzeitige Feedbackschleifen an die Entwicklungsabteilung möglich. Das Fachteam weiß sofort, ob sie alles wie im Design vorgegeben richtig umgesetzt haben oder vielleicht längst in die falsche Richtung marschiert sind. Der Integrationstest ist dann erfolgreich, wenn das gebaute Design richtig umgesetzt ist und so wie vorgesehen funktioniert.
Shift left verschiebt die Timeline
Man spricht hier auch von Shift left: Das Feedback des Business wird auf dem Zeitstrahl nach links verschoben. Dadurch lassen sich Abweichungen der eigentlichen Anforderung früh identifizieren und leicht korrigieren. Gleichzeitig kann sichergestellt werden, dass die komplette Strecke des Requirement Trace nachverfolgbar ist. Anders gesagt: Die ursprüngliche Anforderung kann aus jedem einzelnen Zwischenschritt abgelesen werden bzw. findet sich in diesem wieder. Die Timeline eines S/4HANA-Projektes ist umso weniger gefährdet, umso stärker das Business früh in das Testen einbezogen wird. Entdeckt man Fehler erst vier Wochen vor Go-live, wird es teuer und aufwändig. Dann muss an früherer Stelle im Prozess etwas geändert werden, was Auswirkungen auf alle Folgeschritte hat. Diese müssen dann nochmals getestet werden – eine Verschiebung des Go-Live ist praktisch nicht mehr zu verhindern.
Nach erfolgreichem Durchlauf der Integrationstests schließen sich die eigentlichen User Acceptance Tests, d.h. die Kontrolle des neuen Systems kurz vor seiner Abnahme durch die späteren Anwender:innen. Unit-, Integrations- und User-Acceptance-Tests werden vielfach noch um Migrationstests, Last-, System- und Securitytests ergänzt. Dass die Tests in einer 3- (ggf. auch 4- oder 6-)Systemlandschaft durchgeführt werden sollten, dürfte als Grundvoraussetzung für eine erfolgreiche Transformation als gesetzt gelten.
Automatisierung des Testens
Ob sich die ursprünglichen Anforderungen adäquat im künftigen GUI niederschlägt und gut bedienen lässt, diese Prüfung bleibt letztlich dem Menschen vorbehalten. Viele vorgelagerte Teststufen hingegen lassen sich sehr gut automatisieren. Eine Software führt dabei (über Nacht) die ihr vorgegebenen Klicks durch – was bislang manuell erledigt wurde. Bislang arbeiten noch relativ wenige Unternehmen mit Testautomatisierung. Die damit verbundene Zeitersparnis ist jedoch enorm, wie wir bei SIRIUS aus vielen Migrationsprojekten wissen. Zum Einsatz kommen dafür dedizierte Automatisierungstools (etwa Tosca von Tricents), die parallel zum Testmanagement-Tool, i.d.R. dem SAP Solution Manager, zum Einsatz kommen.
Gerade solche Mammutprojekte wie eine S/4-Transformation sind durch derart viele parallele Arbeiten gekennzeichnet, dass es ohne Automatisierung im Grunde gar nicht mehr geht. Sicher ist da zunächst ein gewisser Aufwand, automatisierte Tests einzurichten. Dies kann man aber genau dann erledigen, wenn Kapazitäten dafür frei sind, nämlich rechtzeitig vor den Peak-Zeiten. Gerade bei bereichsübergreifenden Prozessen ist es später quasi nicht mehr handelbar, alles nochmals erneut von Hand zu testen. Ferner sinkt nicht nur Aufwand, sondern automatisiertes Testen vermeidet auch Flüchtigkeitsfehler und macht selbst beim 100. Durchlauf keinen Tippfehler.
Nicht zu vergessen die alle paar Monate erscheinenden kleineren Releases von SAP, die jedes Mal Testaufwand mit sich bringen. Und für die einmal jährlichen Major Releases kann man die zur Einrichtungsphase aufgebauten automatisierten Tests einfach weiterbenutzen. So rechnet sich das Ganze auch wirtschaftlich.
Titelbild: © Jay Yuno/Getty Images
