Wer debuggt 45.000 Zeilen um zwei Uhr morgens? 975 Tests

Illustration zu „Wer debuggt 45.000 Zeilen um zwei Uhr morgens? 975 Tests“

Bei Code, den kein Mensch mehr Zeile für Zeile geschrieben hat, lässt sich die Frage „Wer debuggt das um zwei Uhr morgens?” nicht mehr über Code-Verständnis beantworten — nur noch über die Testsuite. In der KI-Welt greift man zuerst zum Test, nicht zum Code.

Dafür spricht die bestbelegte Speedup-Geschichte der gesamten Pipeline: Salesforce senkte den Coverage-Aufwand über 76 Repositories von durchschnittlich 26 auf 4 Engineer-Days pro Repository — ein Rückgang um 85 Prozent. IBM berichtet aus einem internen Programm minus 38 Prozent Aufwand bei der Testfall-Erstellung. Und genau hier liegt das Paradox: Während KI den Testaufwand am stärksten senkt, wird die Phase methodisch wichtiger, nicht unwichtiger. Wenn Code aus Spezifikationen entsteht, ist der Test das, was die Lücke zwischen Spezifikation und Realität schließt — er wird zum maschinenlesbaren Spiegel der Anforderung.

Dagegen steht eine hartnäckige Schwäche der Generierung selbst: Sich selbst überlassen, tendiert die KI zu Happy-Path-Tests — in einer Studie bestand nur rund die Hälfte der roh generierten Unit-Tests überhaupt. Coverage- und Mutation-Score-Werte lassen sich zudem gamen: Sie messen die Abwesenheit ungetesteten Codes, nicht die Anwesenheit sinnvoller Prüfungen. Grüne Tests bei steigender Coverage-Zahl beweisen deshalb kein korrektes Verhalten, wie ein eigener Selbstversuch schmerzhaft zeigte, als ein durchweg grün getestetes Buchhaltungs-Teilsystem in Produktion trotzdem kaputt war.

Das Sicherheitsnetz ist nur so gut wie das menschliche Urteil darüber, wovor es überhaupt schützen soll.

Mehr zum Buch und zum Kapitel „Test (Modul, Integration, System, UAT)”

Diskussion

Gedanken, Rückfragen oder Widerspruch? Schreib gern einen Kommentar — nach einer kurzen Sichtung erscheint er hier.