Software getestet, Prozess nicht: Warum ein grüner Test nichts über den Betriebstag sagt

„Die Tests sind alle grün.“ Kennst du diesen Satz? Ich liebe ihn. Und ich habe gelernt, ihm zu misstrauen.

In einem meiner aktuellen Projekte steht der Go-live vor der Tür. Die Software wurde getestet. Zweimal sogar. Alle Meilensteine technisch erreicht, Systeme stabil. Toll, oder? Dann habe ich eine harmlose Frage gestellt: „Wer von den Leuten, die am ersten Betriebstag tatsächlich die Eingaben machen, hat den Ablauf schon einmal von Anfang bis Ende durchgespielt?“ Stille. Dann: „Das war nicht Teil des Tests.“

Eben.

Probleme

Software-Tests prüfen Software, nicht Menschen

Ein Software-Test beantwortet die Frage: Tut das System, was in der Spezifikation steht? Das ist wichtig. Aber am Betriebstag sitzt da nicht die Spezifikation, sondern Heinz. Und Heinz bekommt um 6:15 Uhr eine Meldung, die er so noch nie gesehen hat. Was tut er? Er schaut in die Handlungsanweisung. Die ist von 2019. Oder es gibt gar keine. Also ruft er Karl an. Karl ist im Urlaub.

Die Software hat in diesem Moment übrigens einwandfrei funktioniert. Hilft nur keinem.

Die Lücken liegen an den Schnittstellen

Je mehr Organisationen an einem Prozess beteiligt sind, desto mehr Übergaben gibt es. Und genau dort knallt es. Nicht im System A und nicht im System B, sondern dazwischen: in der E-Mail, die jemand schreiben muss, in der Zahl, die jemand von einem Bildschirm in den anderen abtippt, in der Rückfrage, von der keiner weiß, an wen sie geht.

Lass uns kurz rechnen. Angenommen, dein Prozess hat 12 Schritte über mehrere Teams hinweg. Und angenommen, jeder einzelne Schritt klappt am ersten Tag mit 95 % Wahrscheinlichkeit. Klingt solide, oder? 0,95 hoch 12 sind rund 54 %. Die Wahrscheinlichkeit, dass der gesamte Ablauf beim ersten Mal sauber durchläuft, ist also kaum besser als ein Münzwurf. Und 95 % pro Schritt ist bei Leuten, die den Ablauf noch nie geübt haben, eher optimistisch.

Der Test ist veraltet, bevor er fertig ist

Im Mai wurde getestet, im August noch einmal. Seitdem wurde die komplette Middleware ausgetauscht, es kamen Bugfixes, und bis kurz vor Go-live sind weitere Änderungen geplant. Der grüne Haken aus dem Sommer sagt also streng genommen etwas über ein System aus, das es so nicht mehr gibt.

Niemand fühlt sich für den Gesamtprozess zuständig

Jeder Beteiligte ist für seinen Teil verantwortlich. Und jeder Teil ist getestet. Wer aber ist für das Zusammenspiel verantwortlich? Spoiler: oft niemand. Und wenn du eine Prozessübung vorschlägst, bekommst du gerne mal die Antwort „Das können wir nicht organisieren“, mit einer formal einwandfreien Begründung. Ich behaupte: Die Begründung ist selten das eigentliche Problem. Das Problem ist, dass die Übung Arbeit macht und keiner sie im Budget hat.

Ich weiß, das waren jetzt viele Probleme. Aber genau so sieht es aus, wenn ein Projekt kurz vor dem Ziel ist. Was also tun?

Lösungen

Trenne Software-Test und Prozessübung klar

Formuliere drei getrennte Prüfziele, und zwar schriftlich:

1. Funktioniert die IT?
2. Sind die Prozesse und Handlungsanweisungen dokumentiert und brauchbar?
3. Funktioniert das Zusammenspiel über die Organisationsgrenzen hinweg?

Ein Software-Test beantwortet nur die erste Frage. Wenn du das so hinschreibst, sieht jeder Stakeholder sofort, dass zwei Drittel fehlen. Das ist die halbe Argumentation.

Übe mit den Menschen, die es am Ende tun

Keine Projektmitarbeiter, die das System seit Monaten kennen. Sondern die Leute, die am Betriebstag tatsächlich am Bildschirm sitzen. Und zwar mindestens in der Besetzung, die es auch im Echtbetrieb gibt. Wenn dort zwei Rollen getrennt arbeiten, brauchst du in der Übung auch zwei Personen. Sonst testest du wieder nur, ob Heinz mit sich selbst gut zusammenarbeitet.

Wohlgemerkt: Die Testumgebung muss nicht perfekt sein. „Produktionsähnlich“ reicht. Es geht nicht um das letzte Prozent Software-Qualität, es geht um die Abläufe.

Werte fehlende Anleitungen als Ergebnis, nicht als Scheitern

Das ist für mich der wichtigste Punkt. Wenn in der Übung herauskommt, dass es für einen Fall keine Handlungsanweisung gibt oder die vorhandene veraltet ist, dann ist das kein Misserfolg. Das ist genau das Ergebnis, für das du die Übung gemacht hast! Daraus wird eine konkrete neue Arbeitsanweisung. Lieber jetzt in der Übung als am ersten Betriebstag um 6:15 Uhr.

Hol dir den Auftrag von der richtigen Stelle

Eine Prozessübung ist ein Betriebsthema, kein IT-Thema. Wenn du sie bei den IT-Verantwortlichen platzierst, bekommst du eine IT-Antwort. Sprich die Verantwortlichen für den Betrieb an. Und noch besser: Lass die Organisationen, die am Ende mit den Folgen leben müssen, die Übung selbst einfordern. Dann bist du nicht mehr der lästige Projektleiter, der „noch einen Test“ will, sondern der, der ihnen hilft.

Plane den Notnagel gleich mit

Und wenn nicht alle mitmachen? Dann spiel die wichtigsten Geschäftsvorfälle wenigstens mit den Beteiligten durch, die du hast. Ein verkürzter Durchlauf mit den kritischsten Fällen ist keine gute Lösung. Aber er ist deutlich besser als gar keine, und meistens kannst du ihn ohne großes Abstimmungstheater umsetzen.

Fazit

Ein grüner Software-Test sagt dir, dass dein System funktioniert. Er sagt dir nicht, dass dein Betrieb funktioniert. Das sind zwei verschiedene Fragen, und die zweite wird viel zu oft gar nicht gestellt.

Dein nächster Schritt: Nimm dir deinen nächsten Go-live und schreib die drei Prüfziele auf ein Blatt. Hak ab, welche davon wirklich getestet wurden. Wenn hinter Punkt 2 und 3 kein Haken steht, weißt du, was du nächste Woche zu tun hast.

Ich wünsche dir viel Erfolg bei der Umsetzung dieser Ideen!

Wenn du Fragen hast oder wenn ich dich bei der Umsetzung unterstützen kann, sprich mich gerne an!

In jedem Fall denk immer daran: Das Leben ist zu kurz, um in beschissenen Projekten zu arbeiten!