Das X markiert das Ziel
Bei einem internationalen Kunden fand der Go-Live eines umfangreichen, mehrjährigen und geschäftskritischen Projektes statt. Der Go-Live wurde schon mehrfach verschoben, aber jetzt waren alle Arbeiten erledigt und das Go kam von allen involvierten Stakeholdern. Nachdem das System live war ging gar nichts mehr. Also wirklich: nichts. Die Unternehmenstätigkeiten kamen zum Stillstand. Damit fing das Fingerzeigen an und eine große Runde wurde einberufen. Hier fragte einer der betroffenen LoB Manager wie es denn sein könnte, dass das SAP System nicht bedienbar ist, keine Aufträge bearbeitet, Rechnung gestellt oder bezahlt werden können. Warum die Teams wieder so arbeiten wie vor 40 Jahren: mit Papier und Bleistift. Ob denn in all den Jahren die Grundfunktionalität nicht getestet wurde. Ob man denn überhaupt professionell gearbeitet hätte.
Das konnte die für die Tests zuständige Person nicht auf sich sitzen lassen und intervenierte aufs heftigste. Um zu zeigen das man sehr wohl das Beste gegeben hat, wurde eine Excel Datei gezeigt. Diese zeigte die Projektphasen und Aufgaben dar. Voller Stolz zeigte die Person auf den Abschnitt Tests. „Wir haben getestet! Hier ist der Beweis!“. Und markierte die Zelle in der Testzeile wo ein X stand.
Großes Schweigen im Saal. Dann die Frage: „Und was war das Ergebnis der Tests?“
Hier viel dann die Rechtfertigung in sich zusammen. Das X war da und zeigte das man getestet hatte, aber die Testergebnisse hatte man ignoriert. Seit dem Projektstart vor vielen Jahren waren die Testergebnisse nicht gut. Es war klar das es ein Problem geben wird. Aber das X war wichtiger, denn es zeigt ja, dass man die Tests ausgeführt hat.
3 Comments
Helmut Tammen · February 22, 2021 at 20:15
Hallo Tobias, ähnliche Excels kenne ich auch, aber hast du eine Lösung für dieses Dilemma? Automatisierte Tests wären natürlich eine gute Lösung. Die Tests werden häufig von Mitarbeitern der Fachabteilungen durchgeführt, die weder das Know-how noch die Zeit haben diese Tests zu schreiben. Ich habe schon oft frühzeitig darauf hingewiesen, dass wir eine gute Teststrategie brauchen. Alle waren begeistert und haben mir Recht gegeben.
Wenn ich dann angemerkt habe, dass wir 15% oder mehr für die Entwicklung automatisierter Tests ausgeben müssten, war das Thema immer ziemlich schnell vom Tisch.
Ich habe noch keine Lösung dafür gefunden.
Tobias Hofmann · February 23, 2021 at 09:18
Hallo Helmut,
auch mit automatisierten Tests bleibt das Grundproblem bestehen: die Auswertung. Damit diese auch funktioniert, braucht man dazu noch gute Testdaten. Normalerweise hat man ja schon das Problem Testdaten zu bekommen mit denen man die Szenarien durchgehen kann. Hier gilt oft: wir haben etwas in QA, aber richtige Daten nur in PRD.
Von der Sicht der einzelnen App ist das schon recht schwierig. Wer eine Bibliothek schreibt, ja der kann 100% Abdeckung erreichen. Bei einer App ist das schon wieriger. In der Regel kommt es noch kurz vor dem Go-Live zu UI Änderungen. Es dauert dafür einen Test zu schreiben. Hier ist dann auch die Prio das Transportfenster zu erreichen, Tests kommen dann danach. Aber dann wechselt das Team, die Entwickler, etc.
Bei komplexen Lösungen wie einem LoB Prozess kommt hinzu, dass diese ja nicht nur das eine SAP System beinhalten, sondern auch 3rd party Systeme und Unternehmen. Wer einen Abgleich der Stammdaten mit 4 Zulieferern hat, da ist schon die Kommunikation über die Middlewares nicht so einfach. Da ist der Test erfolgreich wenn die Daten stimmen. Bei einer SSO Lösung wo sich dann Menschen, Systeme und Geräte authentifizieren, hilft eine 100% Testabdeckung nicht. Es kommt auf die Daten an, die muss man interpretieren.
Damit sind erfolgreiche Tests eine Einstellungssache, eine Kultur. Und da ist es leider wie immer: erst nachdem man feststellt das hier ein Mehrwert entsteht, den man nicht direkt messen kann, erst dann wird sich auch die Zeit dafür genommen. Nicht nur zum schreiben, viel wichtiger ist die Auswertung. Und die muss dann auch öffentlich sein, also transparent für alle und auch so kommuniziert.
Bei dem Beispiel im Blog war der Druck endlich live zu gehen enorm. Er wurde schon mehrmals verschoben. Die Entscheider gaben auch gemeinsam das OK. Als ein Problem gab war jeder für sich alleine. Und das ist das traurige an der Geschichte. Die notwendige Kultur um so etwas zu vermeiden war nicht vorhanden. Gute Zahlen noch oben weiter zu reichen war halt einfach die erfolgreichere Strategie. Die anderen haben es ja bestimmt nicht anders gemacht, nur ist es dort nicht aufgefallen. Kultur zu ändern, das ist schwierig.
Jörg Müller · February 25, 2021 at 09:55
Hi,
ich sehe das ähnlich wie Tobias. Selbst wenn gute gewissenhafte Entwickler am Werk sind, für alles automatisierte (Unit-)Tests vorbereiten (dürfen) – es sind Unit Tests. Viele Entwickler machen dann sogar noch funktionale Tests zusammen mit dem Key User / Berater des betroffenden Moduls.
SAP Projekte scheitern aber häufig an den integrativen Themen – der vom Berater “designte” Prozess klappt in der Praxis nicht, Stammdaten sind Schrott, Schnittstellen nicht so stabil wie erwartet und irgendwelche Zahlen stimmen am Ende nicht. Ich meine so Themen wie EWM triggert SD, SD macht SAP Standard mit Sonderlocke und im FI stimmen die Zahlen nicht.
Für sowas ist schon das Projekt eine Herausforderung: die Berater sehen nur Ihr Modul/Tellerrand und fühlen sich kaum für den gesamten Prozess verantwortlich. Technisches Verständnis ist sowieso kaum vorhanden und ein integratives Testszenario zu entwerfen, dass genau solche Lücken vor dem Go-Live findet, ist ein Wunschtraum. Es scheitert an der Kompetenz, am Willen, am Budget, … Es gibt immer etwas, was als wichtiger angesehen wird: z.B. das Reporting nach oben.
Wir haben in einem Projekt gute Erfahrungen damit gemacht, das alle vier Wochen im Rahmen von Meilensteinen alle Prozesse entlang am roten Faden vor der großen Runde demonstriert (und gleichzeitig getestet) werden mussten. Das Storyboard war transparent (der abgestimmte Projektscope), der Know-How-Transfer und das Verständnis für die Prozesse war dadurch halbwegs gegeben und wir haben parallel im Solution Manager die Testfälle “gemeinsam abgehakt” bzw. Tickets erstellt. Damit war auch die Transparenz gegeben. Dieses Vorgehen kostet entsprechend mehr… Dieses S/4 Projekt ist übrigens seit zwei Jahren produktiv und war der erste erfolgreiche Go-Live in der Branche.
Das Thema Testen mit Komplexität, Schnittstellen, Bereitstellen von guten Testdaten ist und bleibt im SAP Umfeld eine Herausforderung. Keine Ahnung wie wir das wirklich lösen können. So etwas wie Entwicklungsstopp und damit die Chance, echte Produktionsdaten für die Tests zu verwenden, gibt es ja häufig auch nicht mehr (Stichwort Änderungen und neue Anforderungen auf der Ziellinie). Mal abgesehen von der natürlichen Abwehrhaltung der Betroffenen gegen alles “Neue” und entsprechenden Abwehrmaßnahmen.
Es bleibt spannend und für uns Techniker wahrscheinlich noch lange sehr frustrierend.
VG Jörg