Warum Scrum ohne Testautomatisierung nicht funktioniert (II)

Bild: Pixabay/Charlemagne - Lizenz

Zu den Artikeln die mir bei den kommentierten Links des letzten Monats durchgerutscht sind gehört einer aus der Welt, der den programmatischen Titel Komplizierte Software kostet Deutsche Post viel Geld trägt. In ihm geht es um die gescheiterte Einführung des so genannten New Forwarding Environment (NFE), das Post, IBM und SAP gemeinsam eintwickelt haben um die Prozesse der Postmitarbeiter zu vereinfachen, zu vereinheitlichen und zu beschleunigen. Jetzt, drei Jahre und 350.000.000 € (!) später kommt der Offenbarungseid - das System scheint derartig schlecht zu sein, dass es aus den Märkten die es bereits einsetzen entfernt werden und durch die zurückgeholten Vorgänger-Programme ersetzt werden muss. Beschrieben wird das Problem folgendermassen: "Das System sei extrem anfällig [...]. Trete an einer Stelle ein Fehler auf, führe dies sofort zum Zusammenbruch des gesamten Systems."

Derartig fragile Produkte habe auch ich bereits erleben dürfen - egal ob es um Fehler, Reparaturen oder Erweiterungen ging, jedes mal wenn man sie anfasste gab es einen lauten Knall und alles brach zusammen. Die Aufräumphase im Anschluss dauerte dann Wochen. Einer der Entwickler bezeichnete diese Anwendungen einmal mit dem schönen Begriff "Jenga-Software". Genau wie beim namensgebenden Spiel kam man erstaunlich schnell an den Punkt an, dem man sie nicht mehr berühren konnte ohne dass alles in sich zusammenfiel. Ursachen kann eine derartige Situation einige haben, und keine davon ist schmeichelhaft für das beteiligte Entwicklungsteam (es sei denn, dass ihm vom Management bereits ein kaputter Bestandscode vorgesetzt wurde). Klar ist aber, dass in einer derartigen Situation eine agile (Weiter)Entwicklung nicht mehr machbar ist, denn die lebt ja davon, dass man die Anwendung ständig um- und ausbaut.

Möchte man eine derartige Situation vermeiden hilft eigentlich nur eine umfassende Testautomatisierung in Form von Unit-, Integrations- und Oberflächentests, die jedes einzelne mal durchlaufen müssen wenn neuer oder geänderter Code eingespielt wird. Auf diese Weise wird sofort festgestellt ob durch ihn bestehende Komponenten geschädigt werden, und wenn ja kann man direkt auf die nächstältere Version zurückspringen. Das sagt sich natürlich relativ einfach, ist in der Realität aber eigentlich nur umzusetzen wenn es von Beginn an befolgt wird oder wenn man bereit ist in eine nachholende Testautomatisierung sehr viel Zeit und Geld zu investieren. Wenn man es nicht tut kommt man aber sehr schnell in die Situation in der jetzt anscheinend die Post ist. Und man muss auch schon ein Konzern dieser Größenordnung sein um von derartigen Verlusten nicht in der eigenen Existenz gefährdet zu werden.


Siehe auch: Warum Scrum ohne Testautomatisierung nicht funktioniert (I)