Characterization Tests und Sicherheitsnetz

Characterization Tests und Sicherheitsnetz

0:00 Dieses Modul beschließt den ersten Tag, und es ist das praktischste von allen. Bisher haben wir verstanden und bewertet — jetzt bauen wir das Netz, ohne das morgen keine einzige Änderung verantwortbar wäre. Der Begriff Characterization Test klingt akademischer, als die Sache ist. Es geht schlicht darum, das heutige Verhalten eines Systems festzuhalten, bevor man es anfasst.

0:22 Nicht das richtige Verhalten, nicht das gewünschte — das heutige. Diese Bescheidenheit ist der ganze Trick, und sie ist zugleich der Punkt, an dem die meisten Menschen und die meisten Agenten scheitern.

Characterization Tests und Sicherheitsnetz

0:34 Der Weg durch dieses Modul führt von der Haltung über die Technik zur Qualitätskontrolle. Erst die Frage, was ein solcher Test überhaupt behauptet. Dann die schwierigste Disziplin: beobachtetes und gewünschtes Verhalten auseinanderzuhalten. Dann die praktischen Probleme — wo komme ich überhaupt in diesen Code hinein, wie beherrsche ich Zeit und Zufall, was mache ich mit Testdaten, die ich nicht verwenden darf.

0:57 Und zum Schluss die Prüfung KI-generierter Tests, denn die entstehen schnell und sehen gut aus. Die Tagesübung baut ein vollständiges Netz für die Monatsabrechnung — und misst, wie gut es ist.

Was tut das System heute tatsächlich?

1:09 Fangen wir mit der Frage an, die diesem Testtyp seinen Namen gibt. Sie ist bewusst eng gestellt — und genau deshalb lässt sie sich beantworten, auch in einem System, das niemand mehr versteht. Ein Characterization Test macht eine sehr zurückhaltende Aussage. Er behauptet nicht, dass das Verhalten richtig ist. Er hält fest, dass es so ist.

1:29 Stellen Sie sich einen Gutachter vor, der ein Haus aufnimmt, bevor die Handwerker anrücken: Er fotografiert jeden Riss. Nicht, weil die Risse in Ordnung wären, sondern damit man hinterher weiß, welche neu sind. Genau das passiert hier. Sobald das heutige Verhalten festgehalten ist, verwandelt sich jede spätere Abweichung von einer unbemerkten Nebenwirkung in einen roten Test. Das ist der ganze Mechanismus.

1:55 Der Ablauf ist erfreulich unaufregend, und das soll er auch sein. Testpunkt wählen, Eingaben hineingeben, Ergebnis beobachten, Ergebnis festschreiben. Der schwierige Schritt ist der vierte, und zwar nicht technisch, sondern psychologisch. Sie werden Ergebnisse sehen, die merkwürdig aussehen. Ein Betrag, der auf eine seltsame Weise gerundet ist. Eine Zahl, die bei einem Randfall plötzlich springt. Der Reflex ist, das zu korrigieren, weil man den Test ja gerade schreibt.

2:25 Und die Anweisung lautet: Halten Sie es fest, gerade dann. Warum, sehen wir im nächsten Kapitel. Es lohnt sich, die Logik dahinter einmal auszusprechen, weil sie die ganze Methode trägt. In einem System ohne Tests und ohne Spezifikation kennt niemand das gewünschte Verhalten. Es gibt keine Instanz, die es Ihnen sagen könnte — die Fachabteilung kennt die Regeln von vor zwölf Jahren nicht mehr.

2:49 Sie können also nicht gegen das Gewünschte testen, weil Sie es nicht kennen. Das Beobachtete dagegen können Sie feststellen: Sie führen es aus und schauen hin. Der Test bewertet dann nichts, er macht nur Abweichungen sichtbar. Die Bewertung ist ein zweiter, ganz eigener Vorgang.

Beobachtetes und gewünschtes Verhalten trennen

3:06 Jetzt kommt der schwierigste Teil dieses Moduls. Nicht technisch — im Kopf. Sie werden gleich hören, warum ausgerechnet gute Entwicklerinnen und Entwickler hier am ehesten stolpern. Die Situation ist immer dieselbe: Sie schreiben gerade den Test, Sie sehen ein Ergebnis, das falsch aussieht — und Sie haben die Datei ohnehin offen.

3:26 Der Reflex, das zu korrigieren, ist kein Zeichen von Nachlässigkeit, sondern von Sorgfalt. Genau deshalb ist er so schwer abzustellen. Der richtige Umgang ist: das beobachtete Verhalten festschreiben und den Zweifel getrennt notieren. Und zwar dort, wo wir das in Modul zwei eingeführt haben — im Unknowns Register. Damit ist der Zweifel nicht verloren, er ist nur nicht in diesem Arbeitsschritt.

3:50 Zwei Gründe, und der zweite wiegt schwerer als der erste. Der erste: Sie wissen gar nicht, ob es falsch ist. Vielleicht ist es eine bewusste Sonderbehandlung, deren Begründung nur niemand mehr kennt — genau die Situation, über die wir in Modul eins gesprochen haben. Der zweite Grund ist der entscheidende: Vielleicht verlässt sich jemand darauf.

4:10 Auch auf ein falsches Verhalten kann sich über Jahre etwas eingestellt haben — eine nachgelagerte Auswertung, eine manuelle Korrektur in der Buchhaltung, ein Nachbarsystem. Die Korrektur wird deshalb eine eigene Entscheidung mit eigenem Auftrag und eigener Abstimmung. Nach der Absicherung, nicht während ihr. Der zweite Punkt ist der, den man am ehesten selbst begeht: eine Rundung geradeziehen, weil sie unsauber aussieht.

4:34 Klingt nach nichts und ist in einer Abrechnung eine Verhaltensänderung mit finanzieller Wirkung. Der erste Punkt ist die Variante, die bei KI-generierten Tests systematisch auftritt — dazu kommen wir in Kapitel sieben. Und der vierte ist banal und trotzdem wichtig: Auffälligkeiten nur im Kopf zu behalten heißt, sie am Freitagnachmittag zu verlieren. Schreiben Sie sie auf, während Sie sie sehen.

4:57 Das kostet zwanzig Sekunden.

Testgrenzen und Seams finden

5:00 Kommen wir zum praktischen Hindernis. Das Schreiben eines Tests ist selten das Problem. Das Problem ist, überhaupt an den Code heranzukommen — und die Lösung liegt meistens woanders, als man zuerst sucht. Der Code, den Sie prüfen wollen, hängt an einer Datenbank, ruft ein fremdes System, liest die Uhr, schreibt Dateien. Eine Naht — im Englischen Seam — ist eine Stelle, an der Sie Verhalten beobachten oder eine Abhängigkeit ersetzen können, ohne den Code vorher umzubauen.

5:28 Das „ohne vorher umzubauen“ ist der springende Punkt. Denn wenn Sie erst umbauen müssen, um testen zu können, bauen Sie ungesichert um — und genau das wollten Sie ja vermeiden. Sie stehen also vor einem Henne-Ei-Problem, und die Naht ist der Ausweg. Die praktische Lösung ist meist überraschend einfach: Gehen Sie eine Ebene höher.

5:48 Statt die tief vergrabene Berechnung isolieren zu wollen, prüfen Sie den ganzen Vorgang von außen — Eingaben hinein, Ergebnis heraus. Das ist deutlich gröber, und viele empfinden es als unbefriedigend. Aber es funktioniert sofort, ohne jeden Eingriff, und es trägt die anschließenden Umbauten vollständig mit: Wenn Sie innen alles umstellen und der Vorgang liefert dasselbe Ergebnis, haben Sie genau das nachgewiesen, was Sie nachweisen wollten.

6:13 Ein präziser Test, für den erst umgebaut werden müsste, sichert dagegen nichts ab. Der erste Punkt ist der Zirkelschluss, vor dem ich eben gewarnt habe: für den Test genau das umbauen, was man absichern wollte. Der zweite ist die Erwartungshaltung aus der Neuentwicklung — dort sind feingranulare Tests richtig, hier blockieren sie den Einstieg.

6:33 Der vierte Punkt ist die Ergänzung, damit das nicht als Freibrief für Grobheit missverstanden wird: Wenn der Umbau später Nähte schafft, ergänzen Sie feinere Tests. Der grobe Test war der Einstieg, nicht das Ziel.

Golden Master und Approval Testing

6:45 Jetzt zu einem Verfahren, das für Bestandssysteme wie gemacht ist — besonders für alles, was Berichte, Exporte oder Abrechnungen erzeugt. Der Aufwand ist gering, die Abdeckung erstaunlich groß. Die Idee ist so pragmatisch, dass sie fast wie Schummeln wirkt. Statt einzelne Werte festzuschreiben, lassen Sie den Vorgang über einen festen Datenbestand laufen, speichern die vollständige Ausgabe als Referenz — den Golden Master — und vergleichen künftig dagegen.

7:13 Sie müssen dafür nicht verstanden haben, wie die Ausgabe zustande kommt. Sie stellen nur fest, dass sie gleich bleibt. Für ein System, dessen Regeln niemand mehr kennt, ist das genau die richtige Art von Test: Er verlangt kein Wissen, das Sie nicht haben. Die fünf Schritte sind schnell erledigt, zwei davon verdienen Aufmerksamkeit.

7:32 Schritt drei ist handwerklich entscheidend: Alles Veränderliche muss raus oder festgelegt werden — Zeitstempel, erzeugte Kennungen, Sortierreihenfolgen. Sonst ist Ihr Test morgen rot, ohne dass sich etwas geändert hätte, und nach drei Tagen glaubt ihm niemand mehr. Schritt fünf ist der disziplinarische: Wenn eine Abweichung auftritt, lesen Sie die Differenz.

7:53 Die Referenz einfach zu aktualisieren, ist eine Bewegung von zwei Sekunden — und danach prüft der Test nur noch sich selbst. Warum eignet sich ausgerechnet der Monatsexport des Fahrtenbuchs so gut? Weil er vier Eigenschaften auf einmal mitbringt. Er bündelt viele Regeln in einem Artefakt — Steuerlogik, Formatierung, Sonderfälle laufen alle dort zusammen. Er entsteht ohnehin, Sie müssen also nichts erfinden.

8:18 Seine Struktur ist stabil, was Abweichungen sofort sichtbar macht. Und er liegt genau in dem Bereich, den die Versionshistorie als Hotspot ausgewiesen hat. Mit einem einzigen Test decken Sie damit den Teil ab, der am häufigsten geändert wird.

Zeit, Zufall und externe Systeme beherrschen

8:34 Kommen wir zu den vier Quellen, die Tests unzuverlässig machen. In Bestandssystemen finden Sie alle vier reichlich — und der Umgang mit ihnen ist Ihr erster echter Eingriff in ungesicherten Code. Ein Test, der am Monatsersten anders läuft als am zweiten, ist wertlos — nicht weil er falsch ist, sondern weil niemand ihm mehr glaubt.

8:53 Und in Bestandscode sind genau diese veränderlichen Abhängigkeiten meistens fest verdrahtet: Die aktuelle Zeit wird mitten in einer Berechnung abgefragt, die Kennung direkt an Ort und Stelle erzeugt. Diese Stellen zugänglich zu machen, ist deshalb häufig der allererste Umbau, den Sie in einem Modernisierungsvorhaben überhaupt vornehmen.

9:11 Und das ist eine unangenehme Situation, auf die wir gleich zu sprechen kommen. Was diese vier Quellen verbindet: Sie alle stellen eine Verbindung zur Außenwelt her, die Sie im Test nicht kontrollieren. Und das Gegenmittel ist jedes Mal dasselbe Prinzip — nicht im Code fragen, sondern von außen hineinreichen. Die Zeit wird übergeben statt abgefragt.

9:32 Die Kennungserzeugung wird austauschbar. Der Pfad wird konfigurierbar. Der Zugriff auf ein fremdes System wandert hinter eine Stelle, die man ersetzen kann. Die Fußzeile benennt das Unangenehme dabei: Dieser Umbau ist notwendig, aber er passiert am noch ungesicherten Code. Sie machen also genau das, wovor wir warnen — und deshalb bewusst und in kleinen Schritten.

9:55 Der erste Punkt ist der wichtigste: Behandeln Sie diesen ersten Umbau nicht als Nebensache. Er ist ein eigener, riskanter Schritt und verdient einen eigenen Commit und eine eigene Prüfung. Der zweite ist handwerklich und passiert ständig: Die Uhr wird an fünf Stellen abgefragt, Sie ersetzen drei, und der Test bleibt sporadisch rot. Suchen Sie systematisch.

10:15 Und der vierte beschreibt die Alltagsvariante von Selbstbetrug: Ein Test, der ein fremdes System anspricht, funktioniert meistens — und fällt genau dann aus, wenn Sie unter Zeitdruck stehen.

Testdaten und Datenschutz

10:26 Jetzt eine Frage, die in Modernisierungsprojekten regelmäßig falsch beantwortet wird — nicht aus Böswilligkeit, sondern weil der bequeme Weg so verlockend nah liegt. Der bequemste Weg zu realistischen Testdaten ist ein Auszug aus der Produktion. Beim Fahrtenbuch ist er unzulässig: Fahrten sind Bewegungsdaten namentlich bekannter Personen — wer wann wohin gefahren ist.

10:48 Das ist keine formale Hürde, die man mit einem Vermerk umgeht, sondern eine harte Grenze. Und sie wird in der Praxis regelmäßig überschritten, weil die Daten eben so praktisch sind und weil es sich nur um „einmal kurz zum Testen“ handelt. Genau dieses einmal kurz ist der Punkt, an dem die Entscheidung fällt. Zwei Wege, und der zweite ist meist der bessere — aus einem Grund, der auf den ersten Blick nicht sichtbar ist.

11:12 Zur Anonymisierung: Bei Bewegungsdaten ist sie deutlich schwerer, als es klingt. Namen zu ersetzen genügt nicht — wenige Fahrten zwischen Wohnort und Arbeitsstätte identifizieren eine Person zuverlässig. Der zweite Weg, erzeugte Daten, hat den Vorteil, der in der Fußzeile steht: Sie müssen die Regeln des Datenbestands verstehen, um ihn nachbilden zu können.

11:33 Diese Arbeit fließt direkt in Ihr Systemverständnis zurück. Was Sie hier investieren, sparen Sie in der Erkundung. Der erste Punkt ist die häufigste Selbsttäuschung: Namen ersetzen und das Anonymisierung nennen. Der dritte ist der methodisch interessanteste — erzeugte Daten werden fast immer zu sauber. Sie bilden den Normalfall gut ab und lassen genau die schrägen Fälle weg, wegen derer Sie den Test schreiben.

11:58 Bauen Sie die Ausnahmen bewusst ein: die Fahrt ohne Zweck, den Kilometerstand null. Und der vierte verweist auf Modul elf: Bevor Sie Daten in ein Werkzeug geben, muss geklärt sein, welche Datenklasse dort überhaupt hindurchlaufen darf.

KI-generierte Tests im Bestand kritisch prüfen

12:12 Zum Abschluss die Qualitätskontrolle. Ein Agent schreibt Ihnen in Minuten fünfzig Tests. Sie sehen gut aus, sie laufen durch, sie sind grün. Und genau daraus folgt die Vorsicht. Es gibt hier einen unangenehmen Zusammenhang: Je schneller und gründlicher die Tests entstehen, desto weniger genau schaut man sie an. Fünfzig grüne Tests fühlen sich wie ein Sicherheitsnetz an. Ob sie eines sind, hängt an Fragen, die man dem Ergebnis nicht ansieht.

12:40 Vier Fehlerbilder treten dabei regelmäßig auf, und keines davon erkennen Sie beim Überfliegen — jedes erzeugt Tests, die syntaktisch einwandfrei sind, sinnvoll benannt und grün. Schauen wir sie uns einzeln an. Die Logik dieser vier Bilder: Sie unterscheiden sich darin, wann der Schaden sichtbar wird. Das erste merken Sie meistens sofort — der Test ist rot, weil das Modell aufgeschrieben hat, was der Code seiner Lesart nach tun sollte.

13:05 Unangenehm ist die Variante, in der er trotzdem grün ist, aber aus dem falschen Grund. Das zweite Bild merken Sie nie: Ein Netz aus Belanglosigkeiten sieht dicht aus und fängt nichts. Das dritte ist das teuerste, wie die Fußzeile sagt — Tests, die an Interna kleben, brechen bei jedem Umbau, und nach drei Wochen zieht das Team sie nur noch nach, statt ihnen zu glauben.

13:27 Diese Gegenprobe ist die wichtigste Technik des ganzen Moduls, und sie dauert fünf Minuten. Ändern Sie eine Zeile im Produktivcode absichtlich — eine Konstante, ein Vergleichsoperator. Lassen Sie die Tests laufen. Wird keiner rot, prüft Ihr Netz an dieser Stelle nichts, egal wie viele Tests es enthält. Das ist eine Beobachtung, keine Einschätzung, und deshalb ist sie so wertvoll.

13:50 Machen Sie das mit fünf Stellen, und Sie kennen die Güte Ihres Netzes als Zahl. Schritt fünf ist die Konsequenz: Was nichts gemerkt hat, wird ersetzt, nicht ergänzt.

Tagesübung: Testnetz für ein ungetestetes Modul

14:01 Die Tagesübung führt alles zusammen — und sie endet nicht mit dem fertigen Netz, sondern mit seiner Vermessung. Das ist der Unterschied zwischen einem Netz und dem Gefühl, eines zu haben. Sie nehmen sich die Monatsabrechnung vor — den Hotspot aus der Versionshistorie, praktisch ohne Tests. Das ist bewusst der unangenehmste Teil des Systems.

14:21 Kombinieren Sie beide Verfahren: eine Golden-Master-Prüfung des gesamten Exports für die Breite, und gezielte Tests für die Regeln, die Sie in Modul zwei gefunden haben — einschließlich der Sechzig-Kilometer-Grenze — für die Tiefe. Vergessen Sie das Festlegen von Zeit und erzeugten Kennungen nicht, sonst ist Ihre Referenz morgen wertlos. Und dann kommt der Teil, auf den es ankommt.

14:44 Schritt fünf ist der eigentliche Kern dieser Übung. Fünf absichtliche Veränderungen im Code, und Sie zählen, wie viele auffliegen. Das ist die einzige belastbare Aussage, die man über ein Testnetz treffen kann — alles andere ist Selbsteinschätzung. Erwarten Sie nicht fünf von fünf. Drei von fünf ist ein normales erstes Ergebnis, und die zwei, die durchgerutscht sind, benennen die Lücke präzise.

15:07 Genau diese Lücken sind Ihre Arbeit für morgen früh — denn ab Tag zwei fangen wir an, das System tatsächlich zu verändern.