Warum geschäftskritische Anwendungen automatisierte Tests brauchen

Bei Anwendungen, von denen Umsatz, Produktion oder Kundenservice abhängen, ist jedes Update mit einem Risiko verbunden. Die Software soll sich weiterentwickeln und darf dabei aber nicht ausfallen. Automatisierte Tests bringen beides zusammen, weil jede Änderung geprüft wird, bevor sie den Betrieb erreicht. Wie das funktioniert und für wen sich der Aufwand lohnt, zeigen wir in diesem Artikel.

Eine geschäftskritische Anwendung ist mit dem Livegang nicht fertig. In den Jahren danach kommen neue Funktionen hinzu, Schnittstellen zu anderen Systemen ändern sich und das Framework braucht regelmäßig Sicherheitsupdates. Jede dieser Änderungen greift in Code ein, auf den sich der laufende Betrieb verlässt.

Das typische Risiko dabei ist eine Regression: Eine Funktion, die bisher zuverlässig lief, arbeitet nach einer Änderung an anderer Stelle plötzlich fehlerhaft. Ein neues Rabattfeld im Bestellprozess kann zum Beispiel die Rechnungsstellung beeinflussen, obwohl dort niemand etwas angefasst hat. Solche Fehler fallen oft erst auf, wenn Kunden oder Mitarbeitende darüber stolpern.

Von Hand lässt sich das auf Dauer kaum absichern. Mit jeder neuen Funktion wächst die Liste dessen, was nach einer Änderung nachgeprüft werden müsste, bis irgendwann nur noch stichprobenartig getestet wird. Wie lange ein Ausfall dauern darf und was er kostet, hängt vom einzelnen System ab. Wie man das einordnet, beschreiben wir im Artikel „Was macht Software geschäftskritisch?“

Automatisierte Tests sichern geschäftskritische Anwendungen ab, indem jede Änderung gegen das gesamte festgelegte Verhalten der Anwendung geprüft wird, bevor sie live geht. Fehler fallen dadurch während der Entwicklung auf und erreichen den Betrieb deutlich seltener. Die meisten Vorteile zeigen sich in den Jahren nach dem ersten Release, wenn die Anwendung wächst und immer mehr Menschen und Prozesse von ihr abhängen.

Die bekannteste Untersuchung dazu stammt von Forschenden von Microsoft Research, IBM und der North Carolina State University. Sie haben vier Teams von Microsoft und IBM, die testgetrieben arbeiteten und ihre Anwendungen dadurch von Anfang an mit Tests abdeckten, mit Projekten ohne TDD verglichen. Bei den testgetrieben arbeitenden Teams lag die Fehlerdichte vor dem Release um 40 bis 90 Prozent niedriger.

Da die Testsuite bei jeder Änderung einmal vollständig durchläuft, fällt eine falsche Funktion auf, bevor die Änderung live geht. Das Team sieht genau, welcher Test fehlschlägt, und kann den Fehler beheben, solange er noch niemanden betrifft. Prüfungen, für die man von Hand Tage bräuchte, dauern so wenige Minuten.

Tests halten in ausführbarer Form fest, wie sich die Anwendung verhalten soll. Wechselt jemand im Team oder übernimmt ein neuer Dienstleister das Projekt, bleibt dieses Wissen erhalten und wird bei jeder Änderung überprüft. Eine Anwendung, deren Verhalten nur in den Köpfen einzelner Personen dokumentiert ist, wird dagegen mit jedem Personalwechsel riskanter.

Frameworks und Bibliotheken erhalten nur einige Jahre lang Sicherheitsupdates. Danach steht ein Versionswechsel an, der viele Stellen der Anwendung gleichzeitig berührt. Mit einer vollständigen Testsuite zeigt sich nach dem Update sofort, welche Funktionen angepasst werden müssen. Ohne sie muss man die Anwendung per Hand prüfen oder das Upgrade aufschieben und damit bekannte Sicherheitslücken offen lassen.

Automatisierte Tests machen die erste Version einer Anwendung teurer, weil zu jeder Funktion auch die passenden Tests entstehen. Die Teams aus der Microsoft-und-IBM-Studie schätzten ihren Mehraufwand in der ersten Entwicklungsphase auf 15 bis 35 Prozent. Dieser Aufwand fällt einmal an, die Testsuite wird dagegen bei jeder späteren Änderung wieder genutzt.

Bei einer Anwendung, die zehn Jahre oder länger läuft, entsteht ein großer Teil der Arbeit nach dem Livegang. Jede neue Funktion, jedes Sicherheitsupdate und jedes Upgrade profitiert von den Tests, die zu Beginn geschrieben wurden. Je länger eine Anwendung im Einsatz ist, desto häufiger zahlt sich der anfängliche Mehraufwand aus.

Nicht sinnvoll ist eine vollständige Testabdeckung bei Software mit kurzer Lebensdauer, etwa bei Prototypen, mit denen eine Idee geprüft und anschließend verworfen wird. Dort zählt vor allem, schnell etwas Vorzeigbares zu haben.

Ein Test prüft nur, was vorher als Anforderung formuliert wurde. Fehler, an die niemand gedacht hat, Lastspitzen oder das Verhalten fremder Systeme im Betrieb bleiben damit unentdeckt. Bei geschäftskritischen Anwendungen laufen Änderungen deshalb zusätzlich über eine Staging-Umgebung, also eine Kopie des Produktivsystems, werden schrittweise ausgerollt und im Betrieb überwacht.

Ob ein Dienstleister Tests ernst nimmt, lässt sich im Auswahlgespräch mit vier Fragen herausfinden:

• Laufen die Tests bei jeder Änderung automatisch? Gut ist eine Pipeline, die jede Änderung testet und fehlgeschlagene Änderungen gar nicht erst live gehen lässt.
• Wie hoch ist die Testabdeckung? Die Zahl allein sagt wenig. Der Dienstleister sollte sie aber kennen und erklären können, welche Teile bewusst ungetestet bleiben.
• Sind Tests fester Bestandteil des Angebots? Tauchen sie als optionaler Posten auf, werden sie unter Budgetdruck oft als Erstes gestrichen.
• Wie lief das letzte größere Framework-Upgrade? An der Antwort sieht man, ob die Testsuite auch im Alltag funktioniert.

Automatisierte Tests kosten bei der ersten Version mehr Zeit und holen sie bei jeder späteren Änderung wieder herein. Für geschäftskritische Anwendungen, die über Jahre weiterentwickelt werden, ist das die günstigere Rechnung. Jede neue Funktion und jedes Upgrade wird geprüft, bevor es den Betrieb erreicht, und das Wissen über die Anwendung bleibt im Projekt.