Softwarequalität: Wenn der grüne Haken nichts beweist

Am 1. September 2026 haben wir einen Knopf auf unserer eigenen Website umgestellt. Danach haben wir im Browser nachgemessen, ob Schriftgröße, Farbe und Abstand stimmen.

Alles stimmte. Die Prüfung war sauber, und sie war trotzdem wertlos.

Um den Knopf überhaupt vermessen zu können, hatten wir vorher eine Animation abgeschaltet, die ihn beim Scrollen langsam einblendet. Genau diese Animation hatte unsere Änderung kaputt gemacht. Wir hatten also mit eigener Hand ausgeschaltet, was wir hätten sehen müssen, und bestätigten anschließend, dass alles in Ordnung sei.

Gefunden hat den Fehler ein zweiter Agent, der den fertigen Code las. Nicht unsere Messung.

Warum ein grüner Haken nichts beweist

Eine Prüfung ist im Kern eine Behauptung. Sie sagt: Wenn etwas kaputtgeht, schlage ich an. Grün ist deshalb nur dann eine Information, wenn Rot überhaupt möglich war. War es das nicht, sagt Grün genau nichts, und es sagt dieses Nichts sehr überzeugend. Dabei hat niemand geschummelt. Der Aufbau, der die Messung erst möglich machte, war derselbe Aufbau, der den Fehler unsichtbar machte. Wer prüft, baut sich die Bedingungen dafür immer selbst, und wenn diese Bedingungen ausgerechnet das ausschalten, worum es geht, prüft man am Ende die eigene Vorbereitung.

Wie oft das in anderen Teams passiert, wissen wir nicht. Bei uns war es an einem einzigen Tag zweimal.

Der zweite Fall: dreizehn grüne Prüfungen, die nichts abgesichert haben

Am selben Tag arbeiteten wir an unserem eigenen Werkzeug, an dem Skript, das fertige Änderungen zusammenführt. Seine Sicherheit hängt an einer einzigen Reihenfolge. Zuerst wird der aktuelle Stand hergestellt, dann laufen die Prüfungen darüber. In der falschen Reihenfolge geht Code durch, den nichts geprüft hat.

Wir haben dafür dreizehn neue Prüfungen geschrieben, und alle waren grün. Allerdings hat der prüfende Agent danach eine einzige Zeile verschoben, sodass die Reihenfolge falsch war, und den betroffenen Testbereich noch einmal laufen lassen. Wieder grün, 168 Prüfungen in diesem Bereich ohne einen einzigen Fehlschlag. Die dreizehn neuen hatten die Reihenfolge nie berührt.

Der Test, der fehlte, stellt den früheren Zustand künstlich her und sieht nach, ob wirklich neu geprüft wird (er muss dafür das Ergebnis der vorigen Prüfung nachbilden, was ihn umständlicher macht als die übrigen und zugleich erst brauchbar, weil er nur in genau diesem Zustand anschlagen kann).

Nachdem wir ihn ergänzt hatten, haben wir die Reihenfolge absichtlich zerstört. Drei Prüfungen wurden rot. Dann haben wir den Code zurückgesetzt.

Zwei Regeln seit dem 1. September

Aus diesen beiden Fällen ist bei uns seit dem 1. September 2026 eine feste Arbeitsanweisung geworden, in zwei Teilen.

• Ein neuer Test muss einmal rot gewesen sein. Wer ihn schreibt, macht absichtlich das kaputt, was der Test schützen soll, sieht ihn fehlschlagen und stellt den Code wieder her.
• Der Aufbau einer Prüfung darf nicht abschalten, worum es in der Prüfung geht. Sonst misst man die eigene Vorbereitung.

Der zweite Teil kommt von dem Knopf, der erste von den dreizehn Prüfungen. Beide Regeln kosten pro Prüfung etwa eine Minute. Dennoch sind sie der Unterschied zwischen einer Prüfung und der Erinnerung an eine Prüfung.

Was das für Ihre eigene Software bedeutet

Für Sie als Auftraggeber ist das keine technische Feinheit, sondern die Frage, ob die Zusagen Ihres Dienstleisters gedeckt sind. Software-Qualität wird gern in Zahlen berichtet: so viele Tests, so viel Abdeckung, alles grün. Keine dieser Zahlen sagt, ob eine einzige dieser Prüfungen jemals in der Lage war, Alarm zu schlagen.

Vier Fragen helfen Ihnen dabei, das ohne Softwarekenntnisse im Statusgespräch zu klären.

• Wann war diese Prüfung zuletzt rot? Auf eine Prüfung, die noch nie angeschlagen hat, sollte sich niemand verlassen.
• Zeigen Sie mir, wie sie fehlschlägt. Ein kurzer, absichtlicher Fehler beantwortet die Frage im Gespräch in zwei Minuten.
• Was wird abgeschaltet, damit die Prüfung laufen kann? Was hier genannt wird, ist ungeprüft.
• Welcher Teil unserer Abläufe ist durch keine Prüfung abgedeckt? Eine ehrliche Antwort nennt eine Lücke, keine Zahl.

Müssten wir wählen, nähmen wir drei Prüfungen, die nachweislich fehlschlagen können, statt dreißig grüner. Die dreißig kosten mehr Zeit und sagen weniger. Besonders deutlich wird das, wenn KI den Code schreibt, denn dann entstehen Tests genauso schnell und genauso plausibel wie der Code selbst.

Wer prüft, muss unabhängig sein, und die Prüfung muss scheitern können

Beide Fehler hat nicht der gefunden, der sie gemacht hat.

Dass ein zweiter Prüfer nötig ist, ist die eine Hälfte. Wie viel Prüfung zum Risiko passt, ist eine eigene Abwägung und steht hier nicht zur Debatte. Die andere Hälfte wird selten ausgesprochen: Auch eine unabhängige Prüfung ist wertlos, solange niemand gezeigt hat, dass sie scheitern kann.

Deshalb steht bei uns beides nebeneinander.

Ein zweiter Agent, am besten auf einem anderen Modell, prüft die Arbeit des ersten, ein Mensch gibt frei, und jede einzelne Prüfung muss einmal bewiesen haben, dass sie rot werden kann.