Testsuite und Prüfläufe

Worum es geht

Ein KI-Agent, der Code schreibt, ist schnell. Schnell falsch zu liegen ist aber kein Fortschritt. Die Frage ist deshalb nicht, ob eine Änderung fertig aussieht, sondern woran man erkennt, dass sie stimmt – und zwar ohne dass jemand sie liest.

Dafür ist über die Projekte hinweg eine eigene Prüfmechanik entstanden. Sie ist nicht eingekauft und nicht aus einem Framework übernommen; sie ist aus konkreten Fehlern gewachsen, jeder davon einmal wirklich passiert.

Zwei Ebenen, die verschiedene Fragen beantworten

Der Durchstich fragt: Läuft die Sache überhaupt durch? Er fährt nicht den frisch geschriebenen Code an, sondern die Naht – die echten Einstiegspunkte, die Oberfläche, die Benachrichtigung, die Laufzeitumgebung. Ein Test, der nur die neue Funktion prüft, sagt nichts darüber, ob sie im Programm ankommt.

Die Regressionstests fragen: Tut alles, was schon einmal funktioniert hat, es immer noch? Sie schützen den Bestand. Jeder gemeldete Fehler wird zum Dauertestfall – damit derselbe Fehler nicht zweimal unbemerkt bleibt.

Beide laufen automatisch mit, keiner muss gestartet werden.

Wo sie eingreift

• Vor jedem Push – ein Hook fährt die Prüfungen der geänderten Projekte und blockt bei Rot. Roter Test heißt: es geht nichts raus.
• Täglich, still – ein Sammellauf über alle Projekte. Meldung nur bei Rot; ein Lauf, der schweigt, hat nichts gefunden.
• Vor der Abnahme – ein Vorgang darf erst in den Abnahmetest, wenn seine Prüfung grün war. Das Ergebnis wird am Vorgang festgehalten, nicht behauptet.

Register statt Gedächtnis

Drei Textdateien tragen das Ganze, absichtlich lesbar und versioniert: eine Registry mit allen Projekten und ihren Prüfungen, ein Fall-Register mit den Fehlern, die nie wiederkommen dürfen, und ein Auswahlregister, in dem steht, was ein Test absichert und woher der Fall stammt.

Daraus wird eine Übersicht abgeleitet, die je Projekt zeigt: welche Tests es gibt, was sie prüfen, wann sie zuletzt liefen und mit welchem Ergebnis. Ganz oben stehen dort nicht die Erfolge, sondern die Lücken – Projekt ohne Suite, Fall ohne Test, Test ohne dokumentierten Zweck.

Die Regeln, die aus Fehlern entstanden sind

• Ein roter Bestandstest wird nie eigenmächtig angepasst. Er geht als Entscheidung an den Menschen: War die Erwartung falsch – oder die Änderung?
• Erwartungen werden abgeleitet, nicht getippt. Ein Test, der einen Textstand festschreibt, wird bei jeder gewollten Änderung rot und bleibt grün, wenn die Sache wirklich bricht.
• Die Gegenprobe gehört dazu. Ein Test, der nie rot wird, prüft nichts. Wer einen schreibt, macht ihn einmal absichtlich kaputt.
• Kein Test ohne Zweck. „Bestanden“ ohne die Angabe, was abgesichert wurde, ist eine Auskunft, mit der niemand etwas anfangen kann.
• Grün ist nicht dasselbe wie geprüft. Ein Projekt ohne Suite wird als Lücke gemeldet, nie still übersprungen.

Was jeder Test schützt

Dauerhafte Zusicherungen stehen als eigener Vorgangstyp im Aufgabenverwaltungssystem – getrennt von den einmaligen Umsetzungsschritten. Jeder Test nennt die Zusicherung, die er absichert.

Damit lässt sich die Frage beantworten, an der die meisten Testlandschaften scheitern: Welche Zusicherung hat gerade keinen Nachweis mehr? Das gefährlichste Ergebnis ist nämlich nicht ein roter Test, sondern eine Zusicherung, die ihren Nachweis verliert und trotzdem grün aussieht.

Offene Kante

Von 13 Projekten in der Registry haben 3 eine Bestandsprüfung. Die übrigen zehn sind über den Durchstich abgedeckt, aber nicht gegen Rückschritte geschützt. Diese Lücke wird von der Übersicht selbst gemeldet und steht hier, weil sie zur Wahrheit gehört.

Ebenso offen: Ein Review durch zweite Augen findet nicht statt, und für die Auslieferung gibt es keinen definierten Rückfall auf die vorige Fassung.

← zurück zur Projekt-Übersicht