Grün heißt nicht geprüft: Warum KI-generierte Tests lügen — und wie man sie ehrlich macht

Ein KI-Agent kann Ihnen über Nacht 400 Tests schreiben. Fast alle werden grün. Das fühlt sich nach Fortschritt an — und ist die gefährlichste Stelle im ganzen Vorhaben. Denn ein grüner Test beweist nicht, dass Ihr Code funktioniert. Er beweist nur, dass der Test nichts gemerkt hat. Das ist nicht dasselbe, und der Unterschied kostet Sie irgendwann einen Produktionsausfall.

Wir generieren Tests inzwischen routinemäßig mit Agenten — schnell, in Review-Qualität, in großem Umfang. Aber die eigentliche Arbeit beginnt erst danach. Ein Test, der eine Aussage trifft, die gar nicht falsch sein kann, ist schlimmer als kein Test: Er färbt die Ampel grün und nimmt Ihnen den Anlass, genauer hinzusehen. Hier ist, woran wir KI-Tests scheitern sehen — und das Verfahren, mit dem wir jeden einzelnen davor zur Rede stellen.

Die drei Arten, wie ein grüner Test lügt

1. Die Tautologie — der Test prüft seine eigene Vorgabe

Der häufigste Defekt. Der Test stellt die Daten so ein, dass das erwartete Ergebnis erzwungen ist — egal, was der Code dazwischen tut.

Ein Beispiel aus der Praxis: Eine Funktion summiert Lohn-Bestandteile über mehrere Zeilen und bildet eine Gesamtsumme. Der Test ersetzt die Summier-Funktion durch eine Attrappe, die schlicht „Anzahl der Elemente” zurückgibt — und prüft dann, ob die Gesamtsumme der Zeilenanzahl entspricht. Sie tut es. Immer. Auch wenn die Funktion das Falsche summiert, das Doppelte zählt oder eine Zeile vergisst. Der Test ist grün, weil die Attrappe die Antwort vorgibt, nicht weil der Code stimmt.

Die Heilung: Die Attrappe muss inhaltssensibel sein. Lässt man jede Zeile einen echten, unterscheidbaren Wert beitragen (20 € und 10 €) und prüft die Summe gegen 30 €, kann der Test plötzlich scheitern — und genau das ist sein Job.

2. Wrong-but-green — die Zeitzonen-Falle

Manche Tests sind heute grün und nächsten März rot, ohne dass jemand etwas ändert. Klassiker: ein Test rechnet mit relativen Datumsangaben („vor 30 Tagen”), aber baut die Daten in lokaler Zeit und vergleicht sie gegen UTC. Auf dem Build-Server, der in UTC läuft, passt alles. Auf dem Laptop einer Entwicklerin in Berlin — oder im CI während der Sommerzeit-Umstellung — verschiebt sich das Ergebnis um einen Tag, und der Test fällt scheinbar grundlos um.

Solche Tests sind eine Zeitbombe: Sie untergraben das Vertrauen in die gesamte Suite („ach, der ist halt manchmal rot”), und genau dieses Achselzucken übersieht dann den echten Fehler. Die Heilung ist unspektakulär — Zeitzone im Test fixieren, durchgängig UTC rechnen — aber man muss es sehen. Wir verifizieren solche Fälle gezielt, indem wir den Test einmal unter einer fremden Zeitzone laufen lassen. Ist er dann immer noch grün, war die Korrektur echt.

3. Die zu lockere Behauptung — ein Test, der alles durchwinkt

Der subtilste Fall. Der Test prüft etwas — aber so unscharf, dass die eine Sache, die er beweisen sollte, durchrutscht. Eine Funktion normalisiert ein Datum auf den Monatsersten; der Test prüft nur, ob das Ergebnis „wie ein Datum aussieht”. Löscht jemand die Normalisierung, sieht das Ergebnis immer noch wie ein Datum aus — der Test bleibt grün und hat seinen einzigen Zweck verfehlt. Eine Behauptung muss eng genug sein, dass der erwartete Fehler sie zerbricht. Sonst ist sie Dekoration.

Warum die KI das nicht selbst merkt

Man könnte denken: Wenn ein Agent klug genug ist, Tests zu schreiben, ist er klug genug, schlechte Tests zu erkennen. In der Praxis nicht — und zwar aus einem strukturellen Grund. Der Agent, der einen Test schreibt, ist auf „grün” optimiert. Er hat das Ergebnis gerade selbst konstruiert; er ist der schlechteste Gutachter dafür, ob es etwas beweist. Das ist kein KI-Defizit, das ist menschlich genauso: Niemand findet die Lücken im eigenen Beweis so zuverlässig wie ein Fremder mit Skepsis im Nacken.

Die Lösung ist deshalb keine bessere Schreib-KI, sondern eine getrennte Rolle.

Das Gegenspieler-Verfahren

Wir lassen die geschriebenen Tests von einem Panel unabhängiger Prüf-Agenten angreifen — mit einem klaren Auftrag: nicht loben, Defekte finden. Jeder Prüfer bekommt den Quellcode und den Test nebeneinander und stuft jede einzelne Behauptung als solide, schwach oder defekt ein. Die Leitfrage ist immer dieselbe: Würde dieser Test scheitern, wenn der Code den erwarteten Fehler hätte? Wenn nicht, ist er wertlos, egal wie grün er leuchtet.

Drei Dinge machen das Verfahren wirksam:

• Trennung von Schreiben und Prüfen. Der Prüfer hat kein Interesse daran, dass der Test grün ist. Sein Erfolg bemisst sich daran, Lügen zu finden.
• Mehrere Perspektiven. Wir setzen nicht einen, sondern mehrere Prüfer an, jeden mit eigenem Fokus — Datentreue, Grenzfälle, Platzhalter-Logik. Was der eine übersieht, fängt der andere.
• Ein Mensch an der Abnahme. Die Befunde der Prüfer sind kein Automatismus. Sie laufen zentral zusammen, werden bewertet und gezielt korrigiert — und erst dann wandert der Block in die Codebasis.

Genau dieses Verfahren hat in unseren jüngsten Läufen reihenweise Tests entlarvt, die durch jede normale Pipeline grün durchmarschiert wären: die zirkuläre Lohn-Summe, die zeitzonen-flackernde Mahn-Logik, eine Mail-Prüfung, die zwei verschiedene Datenbank- Abfragen verwechselte und deshalb das eigentliche Verhalten nie testete. Keiner dieser Fehler hätte eine Test-Ampel rot gefärbt. Alle hätten irgendwann in Produktion weh getan.

Was der Mittelstand daraus mitnehmen sollte

KI, die Code und Tests schreibt, ist real und spart echte Stunden — wir nutzen sie täglich. Aber die Kennzahl, auf die es ankommt, ist nicht „wie viele Tests hat die KI geschrieben”. Sie lautet: wie viele dieser Tests würden einen echten Fehler bemerken. Das eine ist Geschwindigkeit, das andere ist Sicherheit — und nur das zweite schützt Sie vor dem Anruf, dass die Rechnungsstellung seit drei Tagen falsch läuft.

Drei Leitplanken, die kein KI-Test-Vorhaben überleben sollte:

1. Grün ist kein Beweis. Behandeln Sie eine grüne Suite als Behauptung, nicht als Tatsache, bis jemand — Mensch oder Gegenspieler-Agent — sie auf Substanz geprüft hat.
2. Wer schreibt, prüft nicht. Trennen Sie die Rolle. Die ehrlichste Prüfung kommt von einer Instanz ohne Interesse am grünen Ergebnis.
3. Der erwartete Fehler ist der Maßstab. Ein guter Test ist einer, der bei genau dem Bug umfällt, gegen den er Sie schützen soll. Alles andere ist Dekoration mit Ampel-Funktion.

Ein Agent, der Ihnen 400 grüne Tests liefert, hat Ihnen Arbeit abgenommen. Ein Verfahren, das von diesen 400 die zwei Dutzend wertlosen findet und ehrlich macht, hat Ihnen einen Ausfall erspart. Den Unterschied merken Sie nicht am Tag der Lieferung — sondern an dem Tag, an dem etwas hätte schiefgehen sollen und es nicht tat.

---

Krynex Labs baut KI-Agenten und -Automatisierung für den Mittelstand — und die Prüfverfahren, die dafür sorgen, dass sie in Produktion halten, was die Demo verspricht. Reden wir über Ihren Anwendungsfall.