Wann sich Testautomatisierung rechnet und wann sie Geld verbrennt

Die Rechnung, die tatsächlich gilt

Auf der Kostenseite stehen drei Posten, nicht einer. Der erste ist die Erstellung, und der ist der kleinste. Der zweite ist die Wartung: jede Änderung an der Oberfläche, an der Schnittstelle oder an der Fachlogik zieht Anpassungen nach sich. Der dritte ist die Analyse von Fehlschlägen, und der wird fast immer vergessen. Ein Test, der einmal im Monat ohne echten Fehler rot wird, kostet jedes Mal die Zeit, die jemand braucht, um das festzustellen.

Auf der Nutzenseite steht die ersparte manuelle Zeit, multipliziert mit der Zahl der Ausführungen, plus ein zweiter Posten, der schwerer zu beziffern ist: die Fehler, die früher gefunden werden. Ein Fehler, der in der Pipeline auffällt, kostet eine Korrektur. Derselbe Fehler nach der Auslieferung kostet eine Meldung, eine Analyse, einen Notfalltermin und im Zweifel eine Entschuldigung beim Kunden. Diesen zweiten Posten unterschätzen Rechnungen regelmäßig genauso stark, wie sie die Wartung unterschätzen.

Daraus folgt eine unbequeme Konsequenz: Der Schwellenwert liegt höher, als die meisten annehmen. Ein Testfall, der zwanzigmal im Jahr läuft und jedes Quartal angepasst werden muss, ist kein guter Kandidat, auch wenn er sich technisch leicht automatisieren lässt. Ein Testfall, der bei jedem Commit läuft und seit zwei Jahren unverändert ist, rechnet sich schon nach wenigen Wochen.

Was zuerst automatisiert gehört

Ganz oben stehen die Kernabläufe, die bei jeder Änderung mitgeprüft werden müssen, weil ihr Ausfall das Produkt unbenutzbar macht: Anmeldung, der wichtigste fachliche Vorgang, der Abschluss einer Bestellung oder Buchung. Diese Wege ändern sich selten, laufen ständig und haben ein eindeutiges Ergebnis. Sie sind auch die Fälle, bei denen ein Fehlschlag sofort ernst genommen wird, und das ist für den Aufbau einer Kultur wichtiger als Abdeckungszahlen.

Direkt danach kommt alles, was sich rechnerisch prüfen lässt: Preisermittlung, Fristen, Berechtigungen, Umrechnungen, Formatierungen. Diese Fälle haben klare Eingaben und klare Ausgaben, sie brauchen keine Oberfläche und keine Umgebung, und ein Test dafür läuft in Millisekunden. Genau hier lassen sich Äquivalenzklassen und Grenzwerte systematisch abdecken, statt zwei Beispiele zu prüfen und zu hoffen.

Die dritte Gruppe sind Schnittstellen. Eine Prüfung gegen die API deckt fachliche Fehler ab, ohne die Oberfläche zu berühren, sie ist deutlich schneller als ein Oberflächentest und wesentlich stabiler, weil sie nicht an Gestaltung hängt. Wenn eure Anwendung eine Schnittstelle hat, ist das der Ort mit dem besten Verhältnis zwischen Aufwand und Aussagekraft.

Der Fall, den viele zuerst angehen und der eigentlich zuletzt gehört, ist der lange Weg über die Oberfläche. Er ist nicht falsch, aber er ist teuer, und er sollte auf die wenigen Wege beschränkt bleiben, die wirklich das Zusammenspiel aller Teile prüfen.

Was manuell besser aufgehoben ist

Alles, was ein Urteil verlangt, bleibt manuell. Ob eine Oberfläche verständlich ist, ob eine Fehlermeldung hilft, ob ein Ablauf sich unnötig umständlich anfühlt, das kann kein Vergleich zweier Werte beantworten. Automatisierte Prüfungen sagen dir, ob das System tut, was ihr erwartet habt. Sie sagen dir nicht, ob eure Erwartung sinnvoll war.

Ebenfalls manuell bleibt exploratives Testen. Der Wert dieser Arbeit liegt darin, dass jemand während des Testens seine Hypothesen ändert und Wege geht, die niemand vorher aufgeschrieben hat. Genau das lässt sich nicht in ein Skript gießen, denn ein Skript kann nur prüfen, was jemand vorher gedacht hat. Teams, die alles automatisieren, verlieren diese Funde und merken es erst, wenn Kunden sie stattdessen machen.

Und manuell bleibt fast alles, was einmal passiert. Eine Abnahme nach einer Migration, die Prüfung eines Zwischenstands, die einmalige Kontrolle eines Datenbestands. Dafür einen automatisierten Test zu bauen, kostet mehr, als ihn dreimal von Hand durchzuführen, und danach steht ein Test in der Suite, den niemand mehr braucht, aber auch niemand löscht.

Der Ebeneneffekt: dieselbe Aussage, sehr unterschiedliche Kosten

Google hat für die eigene Praxis lange eine Verteilung von etwa siebzig Prozent Unit-Tests, zwanzig Prozent Integrationstests und zehn Prozent Ende-zu-Ende-Tests als Orientierung veröffentlicht. Die Zahlen sind kein Naturgesetz und passen nicht auf jede Anwendung, aber die Richtung hält jeder Prüfung stand: Je weiter oben ein Test ansetzt, desto langsamer läuft er, desto mehr Ursachen kann ein Fehlschlag haben und desto mehr Umgebung muss stimmen.

Der Grund ist nicht Geschmack, sondern Kombinatorik. Ein Ende-zu-Ende-Test bindet die Oberfläche, die Anwendungslogik, die Datenbank, das Netz und meistens noch einen fremden Dienst ein. Wenn jede dieser Schichten in neunundneunzig von hundert Läufen tut, was sie soll, dann schlägt der Gesamttest trotzdem in etwa fünf von hundert Läufen aus einem Grund fehl, der nichts mit eurem Code zu tun hat. Genau diese Rechnung ist der Grund für scheinbar zufällige rote Läufe.

Die praktische Konsequenz ist ein zweistufiger Aufbau. Ein schneller Lauf bei jeder Änderung mit Unit- und Schnittstellentests, dessen Ergebnis in Minuten vorliegt, und ein zweiter, langsamerer Lauf mit den wenigen Ende-zu-Ende-Wegen, der nachts oder vor der Auslieferung startet. Wer beides in einen Lauf packt, bekommt entweder einen langsamen Lauf oder eine gestutzte Abdeckung.

Woran ihr merkt, dass die Suite ihren Wert verliert

Das erste Zeichen ist der Wiederholungsknopf. Sobald es normal ist, einen fehlgeschlagenen Lauf einfach noch einmal zu starten, hat die Suite ihre wichtigste Eigenschaft verloren, nämlich dass ein rotes Ergebnis eine Aussage ist. Ab da baut sich Gewöhnung auf, und die betrifft nicht nur die instabilen Tests, sondern auch die zuverlässigen.

Das zweite Zeichen ist die Laufzeit. Wenn niemand die Suite lokal startet, weil sie zu lange dauert, dann wandert die Rückmeldung in die Pipeline und kommt zu spät. Der Ausweg ist nicht mehr Rechenleistung, sondern eine ehrliche Durchsicht: Welche Tests prüfen dasselbe zweimal, welche laufen über die Oberfläche, obwohl sie es nicht müssten, welche sind seit zwei Jahren nie rot geworden und tragen deshalb keine Information mehr.

Das dritte Zeichen ist eine Zahl ohne Deckung. Eine hohe Codeabdeckung sagt aus, welcher Code ausgeführt wurde, nicht welches Verhalten geprüft wurde. Eine Suite, die jede Zeile durchläuft und dabei kaum Zusicherungen macht, erzeugt eine beruhigende Zahl und keine Sicherheit. Wenn eine Abdeckungsvorgabe zur Zielgröße wird, entstehen genau solche Tests, und dann arbeitet die Kennzahl gegen euch.