Qualität: prüfen, dass eine Prüfung etwas prüft¶

Dokumenttyp: Developer Playbook
Status: Draft v0.1
Stand: 2026-08-29
Prinzip: Allgemeine Anleitung mit Praxisbeispiel aus Junctar

Ziel¶

Dieses Dokument beschreibt die Arbeitsweise, mit der man verhindert, dass grüne Tests ein falsches Sicherheitsgefühl erzeugen. Es ist die teuerste Lektion aus einem laufenden Projekt — in Kurzform und auf einen Projektstart zugeschnitten.

Das Grundproblem¶

Ein grüner Testlauf beweist nicht, dass das Gebaute geprüft wurde — nur, dass etwas lief.

Im Praxisprojekt lief eine Testsuite mit 1774 grünen Tests gegen eine leere Datei: Beim Hochladen war der Inhalt verlorengegangen, und eine leere Python-Datei läuft fehlerfrei durch. Grün, vollständig, wertlos.

Alles Folgende ist Werkzeug gegen genau diese Klasse Fehler.

Die vier Fragen vor jeder Messung¶

Diese vier kosten zusammen keine Minute und fangen den Großteil ab:

1. Wie sähe das Ergebnis aus, wenn die Antwort NEIN wäre?¶

Ist es dasselbe wie beim JA, misst die Probe nichts — egal wie plausibel sie wirkt. Das ist die wichtigste einzelne Frage in diesem Dokument.

2. Was passiert bei einer leeren Menge?¶

Eine Prüfung, die nichts findet, meldet „nichts zu beanstanden". Jede automatische Messung braucht deshalb eine Untergrenze, unter der sie selbst fehlschlägt:

geprüft: 0 Dateien  →  0 Fehler  →  grün    ← falsch
geprüft: 0 Dateien  →  "nichts angesehen"   ← richtig

3. Erzeugt mein Durchgang den Fall überhaupt?¶

Ein Durchlauf über alle Formulare mit leeren Feldern prüft, dass nichts abstürzt — er erreicht den gefährlichen Zweig aber nie, denn der entsteht erst mit echter Eingabe. Im Praxisprojekt blieb dadurch eine Übernahme fremder Konten fünf Wochen unentdeckt, obwohl der Sweep die Route jedes Mal angefasst hatte.

Merksatz: Berührt ist nicht geprüft.

4. Ist das ein Muster oder ein Ergebnis?¶

Eine auffällige Zahl fühlt sich an wie ein Fund und ist erst einer, wenn ihre Ursache gemessen ist. Eine Textsuche, die „74 ungetestete Routen" meldet, hat vielleicht nur übersehen, dass die Tests ihre Pfade zusammensetzen.

Die Gegenprobe¶

Nach jeder Reparatur: den Fehler künstlich wieder einbauen und nachweisen, dass die Prüfung rot wird.

1. Ausgangslage: Prüfung läuft, ist grün
2. Sabotage einbauen (auf einer FRISCHEN Kopie, nicht im Arbeitsstand)
3. Prüfung läuft erneut → muss ROT werden
4. Sabotage entfernen → wieder grün

Bleibt sie in Schritt 3 grün, prüft diese Stelle niemand. Das ist der eigentliche Fund — wertvoller als die Reparatur selbst.

⚠️ Eine grüne Sabotage heißt nicht automatisch „Testlücke". Manchmal verhindert eine zweite Regel, dass der sabotierte Zustand überhaupt eintritt. Dann ist der Fund: hier schützen zwei Regeln dieselbe Sache. Erst der Spur nachgehen, dann urteilen — wer sofort „repariert", schafft eine funktionierende Absicherung ab.

⚠️ Eine Sabotage, die alles kaputt macht, misst nichts. Wenn 29 Prüfungen rot werden, sagt das nicht, welche den Fehler fängt. Die Sabotage muss so klein sein wie der Fehler.

Der Bauablauf¶

Aus dem Praxisprojekt, hier auf das Nötige gekürzt:

1. VERSTEHEN   Was ist die Aufgabe — und was gehört ausdrücklich NICHT dazu?
2. MESSEN      Nachsehen statt annehmen: Namen, Zahlen, Verhalten.
3. CHALLENGE   Gibt es einen besseren Weg? (Fragen unten)
4. BAUEN       Kleine Einheit, am Ende lauffähig.
5. BEDIENEN    Die Sache WIRKLICH benutzen, auch den Schreibweg.
6. PRÜFEN      Tests, dann eine Probe für genau diesen Fehler.
7. FESTHALTEN  Changelog, Roadmap, Doku — sonst war die Lehre umsonst.

Jede Stufe darf zurückspringen. Wer beim Messen merkt, dass die Aufgabe anders liegt, geht auf 1 zurück, statt stur weiterzulaufen.

Zu 2 — was „messen" heißt: Feld- und Funktionsnamen nachsehen, nicht erinnern. In dynamischen Sprachen ist die Syntaxprüfung grün, während der Name gar nicht existiert — der Fehler kommt erst zur Laufzeit, oft beim Nutzer.

Zu 5 — warum Bedienen eine eigene Stufe ist: Eine Funktion ohne sichtbare Rückmeldung ist kaputt, auch wenn im Hintergrund alles richtig läuft. Der Knopf wirkt, das Ding entsteht, die Seite danach sagt kein Wort darüber.

Die fünf Challenge-Fragen¶

Ein Challenge, der nichts ändert, war keiner. Wenn danach alles bleibt wie vorher, wurde nicht ernsthaft gesucht.

Diese fünf finden erfahrungsgemäß am meisten:

Was passiert bei 100-facher Datenmenge?
Was sieht ein Nutzer, dem diese Daten nicht gehören?
Was passiert bei leerer Menge — meldet etwas fälschlich „in Ordnung"?
Geht es ohne JavaScript noch?
Baue ich hier etwas zum zweiten Mal?

Frage 5 ist die unterschätzteste: Zwei Aufgaben, die verschieden heißen, sind manchmal dieselbe Arbeit.

Eine Fallensammlung anlegen¶

Das Praxisprojekt führt eine nummerierte Liste wiederkehrender Fehlerklassen (dort inzwischen über zwanzig). Der Wert liegt nicht in der Liste, sondern in der Gewohnheit: Jeder Fehler, der zweimal auftrat, bekommt einen Eintrag mit Nummer, Kurzname und Beleg.

Für ein neues Projekt genügt eine Datei docs/4-betrieb/FALLEN.md mit den vier Fragen von oben als F1–F4. Alles Weitere wächst aus echten Vorfällen — eine abgeschriebene Liste fremder Fallen wird nicht gelesen.

⚠️ In Verweisen darauf keine Anzahl nennen. „Die Fallen", nicht „die 14 Fallen". Eine Zahl in einem Verweis veraltet still, weil ein Verweis nie rot wird — im Praxisprojekt stand zwei Wochen lang „die 14 Fallen" über einer Liste mit 22.

⚠️ Was an Tag 1 NOCH NICHT gilt¶

Ein Playbook, das den Endzustand eines gewachsenen Projekts als Startpunkt verkauft, richtet Schaden an. Diese Dinge aus dem Praxisprojekt gehören bewusst nicht in den Projektstart:

Erst sinnvoll, wenn …	Warum nicht früher
Rollen- und Rechteprüfungen je Betriebszustand	setzt mehrere Rollen voraus — vorher gibt es nichts zu verwechseln
Wächter, die die Reichweite anderer Regeln messen	lohnt erst, wenn dieselbe Regel an vielen Stellen steht
Getrennte schlanke/volle Testläufe	erst wenn der volle Lauf spürbar wehtut (dort: über vier Minuten)
Ein automatischer Betriebsrundgang	braucht einen Betrieb, den man abschreiten kann

Die Regel dahinter: Jedes dieser Werkzeuge ist aus einem konkreten Schaden entstanden. Wer sie ohne den Schaden einführt, hat Zeremonie statt Absicherung — und pflegt sie nach drei Wochen nicht mehr.

Was dagegen ab dem ersten Tag trägt: die vier Fragen, die Gegenprobe und die Gewohnheit, jede Lehre aufzuschreiben.

Ein Wort zur Dokumentationsgröße¶

Im Praxisprojekt sind Changelog und Roadmap auf 900 KB und 750 KB angewachsen — sie sind damit weder les- noch durchsuchbar, und ein Assistent kann sie nicht mehr am Stück aufnehmen. Die Übergabedatei wird dort in datierte Archivdateien rotiert, Changelog und Roadmap aber nicht.

Lehre für ein neues Projekt: Die Rotation von Anfang an für alle wachsenden Dokumente vorsehen, nicht nur für eines. Faustregel: Über etwa 100 KB wandert der ältere Teil nach archiv/<name>-bis-JJJJ-MM-TT.md.

Checkliste¶

[ ] Jede automatische Prüfung hat eine Untergrenze
[ ] Für jede neue Prüfung ist beantwortet: wodurch würde sie rot?
[ ] Der erste Fix hat eine Gegenprobe bekommen
[ ] Testdurchläufe schicken echte Eingaben, nicht nur leere Formulare
[ ] docs/4-betrieb/FALLEN.md angelegt
[ ] Verweise auf die Fallen nennen keine Anzahl
[ ] Rotationsgrenze für wachsende Dokumente festgelegt