Reviews, Tests und unabhängige Prüfung

Reviews, Tests und unabhängige Prüfung

0:00 Dieses Modul beantwortet die Frage, mit der das vorige geendet hat. Wenn Spezifikation, Code und Tests aus derselben Quelle stammen, wer merkt dann, dass etwas nicht stimmt? Die kurze Antwort lautet: niemand — jedenfalls nicht in dieser Konstellation. Deshalb geht es jetzt um Unabhängigkeit. Nicht als moralische Forderung, sondern als Methode: mehrere Blickwinkel auf denselben Diff, eine saubere Trennung zwischen Befund und Reparatur, und eine Teststrategie, die ehrlich benennt, was Automatik leisten kann und was nicht.

Reviews, Tests und unabhängige Prüfung

0:32 Vier Kapitel. Zuerst das Grundproblem: Warum bestätigt sich eine Annahme selbst, wenn Code und Test aus demselben Kontext kommen? Dann das mehrschichtige Review mit vier verschiedenen Linsen. Danach die Triage — also das Sortieren der Befunde, das im Alltag wichtiger ist als das Finden. Und zum Schluss die Teststrategie, mit einer klaren Grenze zwischen erzeugbar und Handarbeit.

Warum Selbstevaluation nicht genügt

0:56 Fangen wir mit dem Effekt an, der dahintersteckt. Er ist nicht neu und nicht spezifisch für Maschinen — Autorinnen und Autoren kennen ihn seit jeher: Den eigenen Text korrigiert man schlecht, weil man liest, was man gemeint hat. Beim agentischen Arbeiten wird daraus ein systematisches Problem. Wenn Spezifikation, Implementierung und Test aus derselben Annahme entstehen, bestätigen sie einander.

1:19 Der Test ist grün, das Review zufrieden — und die Anforderung trotzdem verfehlt. Das ist keine Nachlässigkeit, sondern eine strukturelle Eigenschaft. Stellen Sie sich vor, jemand übersetzt einen Text und prüft die Übersetzung anschließend selbst gegen sein eigenes Verständnis des Originals. Er wird kaum etwas finden, egal wie sorgfältig er ist. Deshalb ist Unabhängigkeit hier keine Zierde, sondern die eigentliche Methode.

1:45 Vier Wege, auf denen die Bestätigung hereinkommt. Der Agent leitet den Test aus seinem eigenen Verständnis ab — nicht aus der Anforderung. Ein Review im selben Kontext kennt bereits die Begründung und findet sie deshalb schlüssig. Der dritte Punkt ist der, der in Kennzahlen sichtbar wird: Abdeckung sagt, wie viel ausgeführt wurde, nicht wie viel geprüft.

2:05 Und der vierte ist psychologisch: Eine bestätigende Antwort fühlt sich wie ein Ergebnis an, ist aber nur eine Wiederholung dessen, was schon feststand. Diese Gegenüberstellung lohnt einen Moment. Links steht jeweils, was gemessen wird, rechts, was fehlt. Eine Zeile wurde ausgeführt — schön, aber gab es eine Zusicherung dazu?

2:26 Ein Pfad wurde betreten — und der Grenzfall daneben? Ein Test ist grün — gegen welches Kriterium aus der Spezifikation? Die Fußzeile fasst es zusammen: Ein Test ohne Bezug zur Anforderung misst die Implementierung an sich selbst. Das ist bei erzeugten Tests besonders wichtig, weil sie oft aus dem Code abgeleitet werden statt aus der Anforderung.

2:48 Der erste Punkt ist die Zustimmungsfalle vom ersten Modul, jetzt an ihrem eigentlichen Ort. Der zweite ist der, den ich am häufigsten sehe: Tests werden nachträglich an das Verhalten angepasst statt umgekehrt — das fühlt sich wie Aufräumen an und dreht die Beweisrichtung um. Der dritte betrifft die Aufmerksamkeit beim Lesen: Gelöschte oder abgeschwächte Zusicherungen sieht man im Diff nur, wenn man gezielt darauf schaut.

3:11 Und der vierte ist eine Ironie: Die Attrappe ersetzt genau die Abhängigkeit, die geprüft werden sollte.

Review mit mehreren Linsen

3:18 Kommen wir zur Lösung. Sie besteht nicht darin, sorgfältiger zu sein, sondern darin, verschiedene Fragen zu stellen — und zwar unabhängig voneinander. Vier Linsen auf denselben Diff, jede mit einer eigenen Suchrichtung, keine kennt die Befunde der anderen. Das ist weniger Aufwand, als es klingt, und deutlich wirksamer als ein zweiter gründlicher Blick derselben Person.

3:40 Der Kern ist die Unabhängigkeit. Vier Prüfungen laufen parallel über denselben Diff, jede mit einer eigenen Frage, und erst danach werden die Ergebnisse zusammengeführt. Der Vergleich, der mir dazu einfällt, ist die Wohnungsabnahme: Der eine schaut auf die Elektrik, der andere auf Feuchtigkeit, der dritte auf das Inventar.

3:58 Würden alle drei gemeinsam durch die Wohnung gehen, würden sie sich gegenseitig anstecken und dieselben Dinge übersehen. Getrennt finden sie verschiedene Sachen — und genau deshalb lohnt der Aufwand. Sehen Sie sich die Fragen an, nicht die Namen. Die erste sucht das Übersehene, die zweite die Ränder des Wertebereichs, die dritte unbelegte Behauptungen — und die vierte prüft gegen die Akzeptanzkriterien.

4:22 Die vierte funktioniert übrigens nur, wenn es eine Spezifikation gibt; ohne sie prüft sie gegen nichts. Die Fußzeile ist praktisch relevant: Prüfbar ist nicht nur ein Pull Request, sondern auch ein Commit, ein Branch, eine einzelne Datei oder schlicht der aktuelle Arbeitsstand. Sie können also schon reviewen lassen, bevor irgendetwas nach außen geht.

4:42 Warum funktioniert das? Erstens finden verschiedene Fragen verschiedene Fehlerarten — das ist fast eine Binsenweisheit und wird trotzdem selten genutzt. Zweitens: Wer die anderen Befunde nicht kennt, wiederholt sie nicht nur, sondern sucht weiter. Drittens liefert die Spezifikation einen Maßstab von außen, und ohne äußeren Maßstab ist jede Prüfung zirkulär.

5:03 Und viertens machen mehrere Stimmen unbelegte Behauptungen sichtbar: Was nur eine Linse behauptet und keine andere stützt, ist ein Kandidat für den Papierkorb. Der erste Punkt hebt den ganzen Nutzen auf: Wenn alle Linsen im selben Kontext laufen, haben Sie vier Meinungen aus einem Kopf. Der zweite betrifft die Voraussetzung — ohne Spezifikation prüft die Abnahme-Linse gegen nichts.

5:26 Der dritte ist der Übergang zum nächsten Kapitel: Die Befundliste ist keine Aufgabenliste. Wer sie so liest, repariert Dinge, die niemand repariert haben wollte. Und der vierte ist menschlich: Lange Listen ermüden, und Ermüdung macht blind für den einen Fund, auf den es ankam.

Befunde einordnen

5:43 Damit sind wir beim Kapitel, das im Alltag den größten Unterschied macht. Befunde zu finden, ist inzwischen billig — Werkzeuge liefern Ihnen mehr davon, als Sie lesen wollen. Die Kunst liegt im Sortieren: Was ist echt, was ist wichtig, und wer ist dafür zuständig? Die Triage hat vier Schritte, und der erste ist der, den man überspringt: die tatsächliche Konsequenz prüfen.

6:06 Nicht „könnte problematisch sein", sondern: Was passiert konkret, wenn das so bleibt? Danach kommt der Schweregrad, dann die Trennung von Fehlalarmen, und schließlich die Zuordnung zu einem von drei Wegen. Diese Reihenfolge ist kein Zufall. Wer mit dem Schweregrad anfängt, vergibt Etiketten, ohne die Wirkung geprüft zu haben — und bekommt eine Liste, in der alles mittel ist.

6:29 Drei Wege, und der mittlere ist der, den Teams am schwersten annehmen. Patch ist klar: ein echter Defekt im aktuellen Diff wird jetzt behoben. Entscheidung ist auch klar: Wenn die Anforderung unklar ist, geht die Frage an einen Menschen und nicht zurück an den Agenten. Aber Defer — also das bewusste Liegenlassen einer Altlast — fühlt sich falsch an, wenn man sie gerade gefunden hat.

6:51 Die Fußzeile sagt, warum es trotzdem richtig ist: Wer alles patcht, zieht fremde Baustellen in den eigenen Pull Request und macht ihn unprüfbar. Ihre Aufgabe: Führen Sie ein Review durch und ordnen Sie die Ergebnisse ein. Die Kategorien stehen auf der Folie — echter Defekt, fehlendes Akzeptanzkriterium, Testlücke, bestehendes Problem außerhalb des Scopes, unbelegte Behauptung, Entscheidungsbedarf.

7:15 Der Hinweis ist wichtig: Prüfen Sie jede Behauptung am Code. Unbelegte Agentenaussagen sind ein eigener Befundtyp, und sie kommen häufiger vor, als man denkt. Lassen Sie einen geprüften Fehlalarm ruhig in der Liste stehen, mit dem Vermerk, dass er geprüft wurde — sonst findet ihn beim nächsten Lauf jemand erneut. Der erste Punkt haben wir gerade behandelt: Schweregrade ohne geprüfte Konsequenz sind Etiketten.

7:39 Der zweite ist eine Frage der Hygiene — Fehlalarme, die in der Liste bleiben, ohne als geprüft markiert zu sein, entwerten die echten Funde. Der dritte ist die Versuchung des Vorbeigehens: Altlasten reparieren, weil man gerade da ist. Und der vierte ist der subtilste: Entscheidungsbedarf wird als Aufgabe an den Agenten zurückgegeben.

7:59 Damit haben Sie die Entscheidung delegiert, ohne es zu merken — und genau das wollten wir vermeiden.

Teststrategie

8:06 Bleibt die Teststrategie. Hier geht es weniger um Testpyramiden als um eine ehrliche Grenzziehung: Was kann man erzeugen lassen, was muss man selbst schreiben — und woran erkennt man, dass eine Teständerung genauer angesehen werden muss? Gerade der letzte Punkt hat es in sich, denn im Diff sieht weniger Testcode zunächst nach Aufräumen aus.

8:25 Automatisch erzeugte Tests sind besser als ihr Ruf, aber sie haben eine klare Obergrenze: der glückliche Pfad plus einige kritische Fehlerfälle. Statuscodes, Antwortformate, Bedienung über sichtbare Rollen und Beschriftungen — das funktioniert gut und spart echte Zeit. Alles darüber ist bewusste Handarbeit. Das ist keine Kritik am Werkzeug, sondern eine nüchterne Beschreibung dessen, was es kann.

8:49 Wer die Grenze kennt, nutzt die Automatik dort, wo sie trägt, und investiert die eigene Zeit dort, wo sie zählt. Lesen Sie die rechte Spalte. Randfälle, Invarianten, Transaktionen, Nebenläufigkeit, Autorisierung — das sind alles Dinge, die man nicht sieht, wenn man vom Code ausgeht. Genau deshalb bleiben sie Handarbeit. Die Fußzeile setzt die härteste Regel dieses Moduls: Sicherheitskritische Tests schreibt ein Mensch.

9:16 Authentifizierung, Rechte, Eingabevalidierung, Kryptografie. Der Grund ist derselbe wie am Anfang des Moduls — man soll denselben Agenten nicht beides tun lassen, erzeugen und bewerten. Diese Empfehlung stammt nicht von mir, sondern aus den einschlägigen Sicherheitsleitfäden. Vier Gründe, warum Teständerungen im Review eine eigene Aufmerksamkeit verdienen.

9:38 Ein gelöschter Test macht die Suite grün, ohne irgendetwas zu beweisen — und im Diff sieht das nach weniger Code aus, was für viele erst mal gut aussieht. Abgeschwächte Zusicherungen sind noch schwerer zu bemerken, weil der Test ja noch da ist. Attrappen können genau die geprüfte Abhängigkeit ersetzen. Und negative Tests und Grenzfälle entstehen selten von allein — sie brauchen jemanden, der gezielt danach fragt.

10:03 Der erste Punkt schließt den Kreis zum Kapitelanfang: Tests werden erzeugt, aber nie gegen die Akzeptanzkriterien gehalten. Dann prüfen sie den Code gegen sich selbst. Der zweite ist ein handwerklicher Klassiker — hart kodierte Wartezeiten erzeugen Läufe, die mal grün und mal rot sind, und nichts zerstört Vertrauen in eine Suite schneller.

10:23 Der dritte: Manuelles und exploratives Prüfen entfällt, weil die Suite grün ist. Und der vierte ist die Grundregel dieses Moduls, noch einmal in klein: Der erzeugende Kontext bewertet nicht die eigene Qualität. Vier Sätze. Dieselbe Annahme in Spezifikation, Code und Test bestätigt sich selbst — dagegen hilft nur ein Maßstab von außen.

10:43 Mehrere unabhängige Linsen auf denselben Diff finden verschiedene Fehlerarten. Triage kommt vor Reparatur: patchen, zurückstellen oder entscheiden lassen. Und erzeugte Tests decken den Hauptpfad ab, während Sicherheit Handarbeit bleibt. Im nächsten Modul schauen wir uns an, wie man solche unabhängigen Prüfungen technisch organisiert — mit Subagents, und mit den Grenzen, die dabei zu setzen sind.