Automatisierte Qualitätsprüfungen

Automatisierte Qualitätsprüfungen

0:00 Das achte Modul zieht die Konsequenz aus allem, was bisher über Prüfkapazität gesagt wurde. Wenn menschliche Aufmerksamkeit der Engpass ist, dann muss alles, was eine Maschine prüfen kann, auch von einer Maschine geprüft werden. Nicht als Ergänzung, sondern als Entlastung. Der rote Faden lautet deshalb: Was maschinell prüfbar ist, gehört weder in Prosa noch in den Review.

0:22 Wir gehen die Prüfstufen der Reihe nach durch — von der billigsten bis zur teuersten.

Automatisierte Qualitätsprüfungen

0:28 Wir bleiben beim Thema Verifikation. Nach den Tests kommen jetzt die übrigen Prüfungen: Typsystem, Linting, Abdeckung, Abhängigkeiten, Architekturregeln, die Pipeline. Für generierten Code sind sie alle wertvoller als früher, und der Grund ist banal: Das Volumen steigt, und eine Maschine ermüdet nicht. Ein Mensch schon, messbar und schnell — das haben wir in Modul vier gesehen. Deshalb lohnt sich jede Prüfung, die ohne Aufmerksamkeit auskommt, heute doppelt.

Compiler, Build und Typsystem

0:57 Fangen wir bei der billigsten Rückmeldung an, die es gibt: der, die vor dem ersten Testlauf kommt. Ein Typsystem wird oft als Formalismus wahrgenommen, als etwas, das man bedienen muss. Es ist in Wahrheit ein Prüfwerkzeug — und gegenüber generiertem Code wirkt es besonders gut, weil es eine ganz bestimmte Fehlerklasse sofort erwischt.

1:18 Ein Typsystem macht ganze Fehlerklassen unmöglich. Und die verbreitetste Halluzination — die Schnittstelle, die es gar nicht gibt — fällt damit sofort auf, noch bevor ein Test läuft. Sie erinnern sich an die gemessenen Zahlen aus Modul eins: erfundene Paketnamen, reproduzierbar über Modelle hinweg. Genau diese Klasse erwischt der Übersetzer.

1:38 Aber, und das ist die Bedingung, man muss die Typen dafür arbeiten lassen. Ein Modell, in dem jeder Zustand darstellbar ist, prüft nichts. Hier sehen Sie den Unterschied an einem kleinen Beispiel. Oben eine Fahrt, bei der der Zweck optional ist. Das ist bequem beim Schreiben und prüft nichts — jeder Zustand ist darstellbar, auch der unsinnige.

2:00 Unten dieselbe Fachlichkeit anders modelliert: Eine Fahrt ist entweder offen, dann hat sie keinen Zweck. Oder sie ist erfasst, dann hat sie zwingend einen. Der Unterschied ist nicht Stil. Im zweiten Fall kann eine erfasste Fahrt ohne Zweck gar nicht mehr entstehen — der Fehler wird unerreichbar statt nur unwahrscheinlich.

2:19 Das ist der Kern: Zustände unmöglich machen, nicht nur prüfen. Und jetzt kommt der Aspekt, der neu ist. Ein Übersetzungsfehler ist eine präzise, maschinenlesbare Rückmeldung — er sagt genau, was falsch ist und wo. Damit kann ein Agent sich selbst korrigieren, ohne dass ein Mensch eingreift. Die Prüfung wandert also vor den Review statt hinein, und das ist genau die Richtung, in die wir alles verschieben wollen.

2:44 Erfundene Schnittstellen fallen dabei sofort auf, nicht erst im Betrieb. Das ist derselbe Gedanke wie in Modul sechs: Was ausführbar ist, muss nicht geglaubt werden.

Linting, Formatierung und statische Analyse

2:54 Drei Werkzeuge, die im Alltag gern in einen Topf geworfen werden und die Verschiedenes leisten. Es lohnt sich, das auseinanderzuhalten — nicht aus Begriffstreue, sondern weil jedes einen anderen Nutzen hat und weil eines davon einen Nutzen hat, der auf den ersten Blick gar nicht nach Qualität aussieht. Achten Sie auf die rechte Spalte, dort steht der eigentliche Wert. Bei der Formatierung ist er überraschend: Sie verbannt Formatierungsänderungen aus dem Diff.

3:20 Das klingt nach Kosmetik und ist in Wahrheit eine Verifikationsmaßnahme — denn im Review steht dann nur noch Inhalt. Sie erinnern sich an Modul fünf: Eine inhaltliche Änderung im Rauschen von zweihundert formatierten Zeilen ist praktisch unsichtbar. Linting fängt Flüchtigkeiten in Masse, statische Analyse findet, was kein Mensch systematisch suchen würde.

3:40 Für generierten Code sind alle drei wertvoller als früher, weil das Volumen steigt und eine Maschine nicht ermüdet. Der erste Punkt ist der wirksamkeitsentscheidende: Eine Konfiguration, die bei jedem Lauf zweihundert Hinweise ausgibt, wird ignoriert — und damit ist sie wirkungslos, egal wie gut die Regeln sind. Der zweite ist verwandt: Regeln, die nur mahnen, statt den Bau abzubrechen, sind Empfehlungen. Weniger Regeln, die wirklich gelten, wirken mehr als viele, die nur reden.

4:09 Der dritte ist ein Zeitfresser in vielen Teams: über Formatierung diskutieren, statt sie wortlos zu automatisieren.

Testabdeckung richtig lesen

4:17 Jetzt zu einer Zahl, die in vielen Organisationen eine Rolle spielt, die sie nicht verdient. Testabdeckung ist eine nützliche Größe — aber nur in einer Richtung. Die andere Richtung wird ständig behauptet und trägt nicht. Sehen wir uns an, was die Zahl tatsächlich hergibt. Und die falsche Richtung wird leider häufiger behauptet als die richtige.

4:38 Abdeckung misst, welcher Code bei den Tests ausgeführt wurde. Mehr nicht. Sie misst nicht, ob dabei etwas geprüft wurde, ob die richtigen Fälle vorkamen oder ob die Prüfungen aussagekräftig sind. Der schlagende Beweis dafür ist einfach: Eine Suite ganz ohne Feststellungen kann volle Abdeckung erreichen. Sie lässt allen Code durchlaufen und behauptet über nichts davon etwas.

5:00 Hundert Prozent, und kein einziger Test würde je rot. Das ist kein konstruiertes Gegenbeispiel, sondern ein Zustand, den man in Projekten tatsächlich antrifft. Zwei Zeilen, und nur eine trägt. Nicht abgedeckter Code ist mit Sicherheit ungeprüft — das ist eine harte, nützliche Aussage, und damit kann man arbeiten. Abgedeckter Code ist möglicherweise geprüft. Das ist keine Aussage, mit der sich etwas anfangen lässt.

5:26 Martin Fowler bringt es auf den Punkt mit einem Zitat von Brian Marick, das ich Ihnen mitgeben möchte: Ich erwarte eine hohe Abdeckung. Manchmal verlangt ein Manager eine. Das ist ein feiner Unterschied — und zwar der zwischen einer Diagnose und einem Ziel. Vier Punkte, die sich aus der Einseitigkeit ergeben. Sehen Sie sich die nicht abgedeckten Stellen an und bewerten Sie das Risiko — das ist die eigentliche Arbeit.

5:52 Geben Sie keine Prozentzahl als Ziel aus, denn sie wird dann erreicht statt erarbeitet. Fowler erwartet bei durchdachtem Testen von selbst Werte in den oberen Achtzigern oder Neunzigern — als Nebenprodukt, nicht als Vorgabe. Und volle Abdeckung riecht für ihn danach, dass jemand für die Zahl getestet hat. Bei einem Agenten passiert das noch zuverlässiger, weil der Aufwand dafür wegfällt.

Abhängigkeiten, Schwachstellen und Secrets

6:15 Jetzt zu drei Prüfungen, die jede Pipeline haben sollte und die schnell eingerichtet sind. Was sie verbindet: Es sind genau die Prüfungen, die ein Mensch im Review praktisch nie zuverlässig leistet. Nicht aus Nachlässigkeit — sondern weil sie stumpfe, gründliche Arbeit verlangen, für die Aufmerksamkeit der falsche Mechanismus ist.

6:34 Die Abhängigkeitsprüfung meldet bekannte Schwachstellen in dem, was Sie mitbringen. Bei generiertem Code ist das besonders relevant, denn Agenten schlagen Bibliotheken vor, die zum Trainingszeitpunkt üblich waren — und die heute überholt oder verwaist sein können. Die Lizenzprüfung verhindert, dass unbemerkt Code mit unvereinbaren Bedingungen ins Produkt gerät. Und die Secret-Prüfung durchsucht Änderungen auf Zugangsdaten.

6:59 Alle drei leistet eine Maschine mühelos. Alle drei leistet ein Mensch im Review praktisch nie zuverlässig — probieren Sie es einmal aus, es ist ernüchternd. Und jetzt der Punkt, der in der Praxis am häufigsten falsch gemacht wird, und zwar mit guten Absichten. Die Reihenfolge lautet: erst rotieren, dann eventuell die Historie säubern.

7:19 Nicht umgekehrt. Der Grund steht in den Schritten drei und vier: Das Entfernen aus dem aktuellen Stand entfernt gar nichts aus der Historie. Jeder Klon trägt die vollständige Historie, und über die Commit-Kennung bleibt der Inhalt abrufbar — auch nach einem Force-Push, auch nach dem Löschen des Branches. Ein einmal veröffentlichtes Geheimnis gilt als kompromittiert. Wer nur säubert, hat aufgeräumt und nicht abgesichert.

Architekturregeln und Fitness Functions

7:44 Damit zu einem Mittel, das ich für unterschätzt halte — und das gegenüber Agenten noch einmal deutlich wirksamer ist als gegenüber Menschen. Es geht darum, strukturelle Entscheidungen ausführbar zu machen. Also aus einer Absicht, die in Köpfen und Dokumenten steht, einen Test zu machen, der abbricht. Der Unterschied zwischen einer Absicht und einem Test ist dabei größer, als er klingt.

8:07 Strukturelle Entscheidungen zerfallen, wenn sie nur in Köpfen und Dokumenten stehen. Nehmen wir die Regel, dass die Fachlichkeit nichts von der Persistenz wissen darf. Die hält genau so lange, bis jemand unter Zeitdruck eine Abkürzung nimmt — und der Review bemerkt sie nicht, weil eine einzelne zusätzliche Einbindung im Diff harmlos aussieht.

8:26 Sie ist ja auch harmlos, für sich genommen. Erst die Summe kippt die Architektur, und die Summe sieht niemand im einzelnen Review. Vier Beispiele aus dem Fahrtenbuch, und sie zeigen die Bandbreite. Abhängigkeitsrichtung: Buchungsregeln kennen die Persistenz nicht. Verbotene Bibliotheken: keine Fließkommazahlen für Geldbeträge — eine Regel, die als Prosa regelmäßig übersehen wird und als Test nie.

8:49 Namensmuster: Prüfregeln liegen im dafür vorgesehenen Verzeichnis. Und Schwellen: Startzeit und Antwortzeit der Abrechnung. Der Begriff dafür stammt aus der Architekturliteratur und heißt Fitness Function — eine Architektureigenschaft, die automatisiert und wiederholt geprüft wird. Entscheidend ist nicht die Vollständigkeit dieser Liste, sondern dass die wichtigsten Regeln überhaupt ausführbar werden.

9:14 Der entscheidende Satz steht ganz oben: Ein Agent kann eine Prosa-Vorgabe übersehen, einen roten Test nicht. Das ist kein Vorwurf — auch Menschen übersehen Prosa-Vorgaben. Nur passiert es beim Agenten häufiger, weil er nicht nachfragt und weil ihm die Konvention nicht in Fleisch und Blut übergeht. Der Bau bricht ab, für jeden gleich, ohne Diskussion.

9:35 Zwei Einordnungen dazu: Nicht jede Architekturabsicht lässt sich fassen — der Anspruch ist Verlagerung, nicht Vollständigkeit. Und die Rechnung ist eindeutig: Der Aufwand ist einmalig, das Prüfen von Hand fällt für immer an.

CI als verbindliche Qualitätsgrenze

9:49 Jetzt zu dem Ort, an dem aus all diesen Prüfungen erst eine Grenze wird. Denn eine Prüfung, die nur lokal läuft, ist eine Empfehlung — sie hängt an der Disziplin des Einzelnen. Erst die gemeinsame Pipeline macht daraus eine Vereinbarung. Und damit sie das leisten kann, braucht sie zwei Eigenschaften. Die Pipeline ist der Ort, an dem ein Team festlegt, was es nicht in seinen Hauptzweig lässt.

10:13 Das ist eine erstaunlich weitreichende Entscheidung, und viele Teams treffen sie nie ausdrücklich. Damit sie trägt, braucht die Pipeline zwei Eigenschaften. Sie muss zuverlässig sein — dazu gleich mehr, denn das ist der kritischere Punkt. Und sie muss schnell genug sein, dass ihr Ergebnis noch zur Änderung gehört. Eine Rückmeldung nach vierzig Minuten kommt für die Arbeitsweise dieses Seminars zu spät.

10:37 Der erste Punkt ist der folgenreichste, und wir sehen ihn uns gleich noch genauer an. Der zweite ist die Geschwindigkeitsfrage von eben. Der dritte betrifft die Verbindlichkeit: Prüfungen nur lokal führen und sich auf Disziplin verlassen — das funktioniert, bis der Termindruck kommt. Und der vierte ist ein Punkt, der noch selten bedacht wird: Dem Agenten die Pipeline nicht zugänglich zu machen, obwohl er sich damit selbst korrigieren könnte.

11:01 Das ist verschenkte Prüfarbeit, die Sie sonst selbst leisten. Diesen Satz meine ich wörtlich, und er überrascht viele. Eine Pipeline, die sporadisch aus unerfindlichen Gründen scheitert, erzieht das Team dazu, rote Ergebnisse zu ignorieren. Man startet neu, es wird grün, man macht weiter. Das ist eine rationale Reaktion. Nur wirkt danach auch der echte Fehlschlag nicht mehr — das Signal ist verbrannt.

11:27 Ohne Pipeline weiß wenigstens jeder, dass er selbst prüfen muss. Mit einer unzuverlässigen glaubt man, geprüft zu haben. Deshalb: wenige Regeln, die wirklich gelten, statt vieler, die nur mahnen.

Fehlermeldungen für Mensch und Agent

11:40 Zum letzten fachlichen Kapitel, und es geht um etwas, das kaum jemand als Qualitätsmerkmal betrachtet: Fehlermeldungen. Sie sind Benutzeroberfläche — und ihre Nutzer sind inzwischen zwei. Ein Mensch und ein Werkzeug, mit unterschiedlichen Folgen, wenn die Meldung schlecht ist. Und schlechte Meldungen kosten heute mehr als früher, weil sie häufiger gelesen werden.

12:02 Eine brauchbare Meldung sagt drei Dinge: was erwartet wurde, was tatsächlich passiert ist, und wo. Fehlt eines der drei, beginnt Ratearbeit. Bei einem Menschen kostet das Zeit — ärgerlich, aber begrenzt. Bei einem Agenten kostet es mehr, und zwar aus einem Grund, der jetzt vertraut sein sollte: Er antwortet auf eine unpräzise Meldung mit einer plausiblen, aber häufig falschen Korrektur.

12:26 Und verschlimmert damit die Lage, statt sie zu klären. Eine Meldung, die nur den Ort nennt, verschiebt die eigentliche Arbeit auf den Leser. Zwei Varianten derselben Prüfung. Oben: Buchung ungültig. Das ist wahr und vollkommen unbrauchbar — es sagt weder, welche Buchung, noch was erwartet wurde, noch was tatsächlich vorlag.

12:46 Unten dieselbe Prüfung mit allen drei Angaben: welche Buchung, welche Erwartung, welcher tatsächliche Wert. Der Unterschied im Aufwand ist eine Zeile. Der Unterschied in der Wirkung ist erheblich, denn aus einem Rateversuch wird eine gezielte Korrektur. Und für den Agenten gilt das buchstäblich: Er hat keinen Kontext außer diesem Text.

13:09 Der erste Punkt ist die häufigste halbe Lösung: Die Meldung nennt den Ort, aber nicht die Erwartung. Der zweite ist noch verbreiteter — der tatsächliche Wert fehlt, obwohl gerade er die Korrektur trägt. Der dritte ist die Begründung, warum das so bleibt: Man steckt in eigene Prüfungen keine Mühe, weil sie ja selten auslösen.

13:27 Und der vierte ist die Erkenntnis, die das ändert: Diese Texte werden jetzt viel häufiger gelesen als früher, weil ein Werkzeug sie bei jedem Durchlauf liest.

Übung: Eine Quality Pipeline, die einen Patch scheitern lässt

13:36 Zum Abschluss bauen Sie selbst eine Pipeline — höchstens fünf Stufen — und schicken einen absichtlich fehlerhaften Patch hindurch. Die eigentliche Frage kommt aber erst danach, und sie hat mit der Pipeline selbst nur mittelbar zu tun. Sie hat mit dem zu tun, was die Pipeline sagt, wenn sie greift. Der Patch soll drei Fehler enthalten: fachlich falsch, eine neue Abhängigkeit, und eine verletzte Abhängigkeitsrichtung zwischen zwei Modulen.

14:02 Drei Fehler, drei verschiedene Stufen — wenn bei Ihnen nur eine greift, fehlt eine Stufe, und das ist bereits ein Ergebnis. Der Kern der Übung ist die Schlussfrage: Reicht die Meldung der zuerst greifenden Stufe aus, damit ein Agent den Fehler ohne menschliche Erklärung beheben könnte? Genau darauf läuft dieses Modul hinaus.

14:21 Fünf Schritte in einer Stunde. Begründen Sie Auswahl und Reihenfolge Ihrer Stufen — welche Stufe fängt welche Fehlerklasse, und warum steht sie an dieser Stelle? Die Reihenfolge sollte den Kosten folgen, wie in Modul fünf. Schicken Sie dann den Patch hindurch und stellen Sie fest, welche Stufe zuerst greift — und ob es die erwartete war.

14:41 Oft ist es nicht die erwartete, und das ist der interessanteste Befund. Bewerten Sie zum Schluss die Meldung dieser Stufe.