Die erste Ausführung testet den Testfall — was ein Testfall wert ist, den noch nie jemand ausgeführt hat

Veröffentlicht 17.09.2026
von

Ein manueller Testfall im DI²-Projekt hatte alles, was die Konvention verlangt: einen Kopf mit Ziel und Vorbedingung, eine Ablauf-Tabelle mit Schritt und Erwartung, einen Eintrag in der Übersicht des Katalogs, Verweise auf die abgedeckten Dateien. Die automatische Formprüfung des Katalogs hatte ihn abgenommen. Beim ersten Ausführen stellte sich heraus, dass es den beschriebenen Weg nicht gibt: Der Ausgangszustand, den der Testfall selbst herstellt, macht die einzige Spalte unbrauchbar, auf der ein späterer Schritt aufbaut.

Am Tag darauf verlangte ein zweiter Testfall in Schritt 6 eine Beobachtung, die am Bildschirm niemand machen kann. Zwei Wochen später lief der Katalog zum ersten Mal vollständig, 30 Testfälle in fünf Suiten, und 16 Testfall-Dateien wurden dabei geändert. Aufgefallen war bis dahin keiner dieser Fehler, und an der automatischen Formprüfung war keiner gescheitert.

Dieser Artikel handelt davon, was die erste Ausführung eines Testfalls tatsächlich prüft: zuerst den Testfall selbst, dann die Anwendung, und manchmal die Anforderung dahinter. Ein Testfall-Review, also das Lesen des Testfalls gegen Code und Datenbank, findet vieles davon vorab. Den ersten Lauf ersetzt es nicht. Die Deklarationen, also die aufgeschriebenen Testfälle, und die Lauf-Protokolle stammen von einem Coding-Agenten, Claude Code in den Modellen Claude Opus 5 und Claude Fable 5. Der Maintainer hat geklickt und geurteilt, auch über die Anforderung.

Das Wichtigste vorab:

  • Eine Testfall-Deklaration kann falsch sein, ohne dass man es beim Lesen sieht: Entweder existiert der beschriebene Weg nicht, oder man kann am Bildschirm gar nicht sehen, ob das Erwartete eingetreten ist. Eine Formprüfung findet beide Fehler nicht, weil sie die Form prüft und nicht die Durchführbarkeit.
  • Der erste vollständige Lauf eines Katalogs prüft zuerst die Testfälle: 16 von 30 Testfall-Dateien wurden im DI²-Projekt dabei geändert. Bei elf dieser 16 Dateien fand nicht das Klicken den Fehler, sondern das Lesen der Deklaration gegen Code und Datenbank unmittelbar davor. Ersetzt hat diese Vorbereitung den Lauf trotzdem nicht.
  • Ein bestandener Lauf belegt nur, was tatsächlich beobachtet wurde: Ein „pass“ aus einem früheren Lauf war falsch. Zwei Rückmeldungen meldeten mehrere Schritte auf einmal als bestanden, und ein Mitschnitt der Datenbank, der während des Laufs mitlief, zeigte nicht alle davon. Das Protokoll gehört pro Schritt geführt, mit dem Mitschnitt als Nachweis.
  • Manchmal kostet ein bestandener Testfall die Funktion, die er prüft: Ein Testfall bestand, und beim Durchklicken fiel die Entscheidung, dass es die geprüfte Funktion gar nicht geben sollte. Der Testfall wurde zurückgezogen statt gelöscht.

Voraussetzung: Keine. Die Beispiele stammen aus einem Katalog manueller Testfälle, der als Markdown-Dateien im Repository einer Web-Anwendung liegt. Die Anwendung verwaltet Tabellen und Spalten einer Datenbank, mehr muss man über sie nicht wissen. Die Prinzipien gelten für jeden Testfall, den ein Mensch nach Anleitung ausführt. Zwei Wörter hält der Text auseinander: Testfall meint einen aufgeschriebenen Ablauf mit Erwartungen, den ein Mensch am Bildschirm ausführt. Test meint eine automatisierte Prüfung, die grün oder rot endet. Um automatisierte Tests geht es im Artikel über den grünen Test, der nichts beweist, hier nicht.

Inhalt

Was eine Deklaration ist und warum sie Fehler haben kann

Ein Testfall im DI²-Projekt ist eine Markdown-Datei mit festem Aufbau: ein Kopf mit Ziel und Vorbedingung, also dem Zustand in der Datenbank vor dem ersten Klick, dann eine Ablauf-Tabelle mit einem Schritt pro Zeile und daneben dem erwarteten Ergebnis, am Ende das Aufräumen. Jeder Lauf bekommt ein eigenes Protokoll, das den Testfall über seine Nummer nennt und ein Ergebnis festhält. Wie ein solcher Katalog aufgebaut ist und woher seine Fälle kommen, beschreibt ein eigener Artikel dieses Blogs.

Diese Datei nennt der Artikel die Deklaration. Sie ist code-artig: Sie beschreibt einen Ablauf, den jemand anderes später ausführt, und sie kann fehlerhaft sein, ohne dass man es beim Lesen bemerkt. Eine automatische Formprüfung sichert den Katalog bei jeder Änderung ab. Geprüft wird dabei nur die Form: Ist der Kopf vollständig, führt die Übersicht den Testfall mit derselben Nummer und demselben Titel, existieren die Dateien, auf die er verweist. Ob sich Schritt 4 nach Schritt 3 überhaupt ausführen lässt und ob man bei Schritt 6 überhaupt sehen kann, ob das Erwartete passiert ist, sieht die Formprüfung nicht.

Man kann eine Deklaration am Code prüfen, und im DI²-Projekt tut das der Agent inzwischen vor jedem Lauf. Er liest die Vorbedingung gegen die Datenbank und die Schritte gegen die Anwendung: Gibt es diesen Zustand, und stellt ihn ein Schritt her? Gibt es diesen Button noch? Das findet viel, wie der Gesamtlauf weiter unten zeigt. Eine Frage beantwortet es nur zum Teil: ob man am Bildschirm überhaupt sehen kann, ob das Erwartete passiert ist. Blendet die Anwendung ein Element in einem bestimmten Zustand aus, steht das im Code. Dass zwei Meldungen für den Betrachter gleich aussehen oder dass eine Markierung im Moment des Klicks verschwindet, fällt dagegen meist erst auf, wenn jemand die Datei neben dem Browser hat.

Kernaussage: Eine Deklaration ist ein Text, der wie Code Fehler enthalten kann. Die Formprüfung des Katalogs findet fehlende Teile, nicht falsche Inhalte. Ob der beschriebene Weg existiert und ob man das Erwartete am Bildschirm sehen kann, weiß man sicher erst nach der Ausführung.

Erster Fehlermodus: Der Weg existiert nicht

Der erste Fall stammt vom 28. August 2026. Die Anwendung zeigt eine Meldung, wenn eine Prüfregel nicht mehr zu der Spalte passt, für die sie angelegt wurde, etwa weil die Spalte inzwischen Text statt Zahlen enthält. Ein Testfall prüft, dass diese Meldung von selbst als gelöst gilt, sobald der Grund beseitigt ist.

Dafür stellt das Setup den Grund zuerst her: eine Spalte auswählen, eine Regel darauf anlegen, die Spalte auf Text umstellen, die Meldung erscheint. Dann nennt der Testfall zwei Wege, den Grund zu beseitigen. Entweder die Spalte wieder zurückstellen. Oder, wörtlich: „die Regel auf eine numerische Spalte umziehen oder löschen“.

Der Umzug geht nicht. Der Testfall arbeitet mit genau einer Spalte, und genau die hat das Setup gerade auf Text gestellt. Eine andere Zahlen-Spalte gibt es in diesem Zustand nicht, und sich eine dazuzuholen, lief zu diesem Zeitpunkt in einen offenen Fehler der Anwendung. Der Testfall war auf diesem Weg nicht abschließbar.

Beim Lesen war das nicht aufgefallen. Die Deklaration las sich schlüssig, die Formprüfung war zufrieden. Aufgefallen ist es beim ersten Ausführungsversuch am selben Abend. Seitdem heißt der zweite Weg nur noch „die Regel löschen“, und das Protokoll nennt den Fund beim Namen: ein Fehler in der Deklaration, nicht im Produkt.

Kernaussage: Ein Testfall kann einen Weg beschreiben, der mit seinem eigenen Ausgangszustand nicht gangbar ist. Keine einzelne Zeile ist dabei falsch, zwei Zeilen widersprechen sich nur. Das sieht man, wenn man den Weg geht.

Zweiter Fehlermodus: Die Erwartung ist nicht beobachtbar

Der zweite Fall liegt einen Tag später und ist unauffälliger, weil der Weg existiert. Ein Testfall prüft, dass beim Deaktivieren einer Tabelle auch ihre Meldungen verschwinden. Das Setup erzeugt an einer Tabelle absichtlich eine Meldung, indem es eine Pflichtangabe leer lässt. Eine zweite Tabelle mit eigener Meldung dient als Kontrolle. Die Schritte 1 bis 5 bestanden: Tabelle deaktiviert, ihre Meldung weg, die der zweiten Tabelle unverändert. Schritt 6 verlangte, die Tabelle wieder zu aktivieren, und erwartete: „Die alten Meldungen kommen nicht zurück.“

Am Bildschirm sah Schritt 6 wie ein Fehlschlag aus: Nach dem Aktivieren stand wieder eine Meldung da, mit demselben Text. War die alte doch zurückgekommen? Die Datenbank sagte nein. Die alte Meldung war beim Deaktivieren gelöscht worden. Die sichtbare war ein neuer Datensatz, angelegt vier Sekunden nach dem Aktivieren. Der Grund: Die leere Pflichtangabe, die die Meldung ausgelöst hatte, hatte das Deaktivieren überlebt. Die Anwendung fand die Lücke erneut und meldete sie erneut. Für den Nutzer sah das aus wie die alte Meldung, im System war es eine andere. Und genau so sollte sich die Anwendung damals verhalten.

Der Fehler lag in der Erwartung. Alte und neue Meldung sehen am Bildschirm gleich aus. Schritt 6 verlangte eine Unterscheidung, die niemand am Bildschirm treffen kann. Die Deklaration wurde noch am selben Mittag geändert. Vorher:

| 6 | Tabelle wieder aktivieren. | Die alten Meldungen kommen nicht zurück. |

Nachher beschränkt sich die Erwartung am Bildschirm auf das Prüfbare, und die eigentliche Aussage wird in der Datenbank geprüft:

| 6 | Tabelle wieder aktivieren. | Besteht der Grund fort, erscheint eine inhaltlich
gleiche Meldung wieder, als offen. Am Bildschirm prüfbar ist nur: Sie kommt als
offen zurück, nicht als gelöste Karteileiche. |

> Schritt 6 braucht eine Gegenprobe in der Datenbank: Ob die Meldung die alte ist
> (Fehlschlag) oder eine neu erzeugte (korrekt), ist am Bildschirm nicht zu
> unterscheiden. Kennung und Anlagezeitpunkt der Meldung müssen nach dem Zeitpunkt
> des Aktivierens liegen. Im Referenz-Lauf: aktiviert 10:24:46, neue Meldung
> 10:24:50, die alten gelöscht.

Diese Fassung hielt fünf Stunden. Am selben Abend lernte die Anwendung, beim Deaktivieren auch die Einstellungen der Tabelle abzuräumen. Seitdem verschwindet der Grund mit, und Schritt 6 erwartet, dass gar keine Meldung erscheint, was am Bildschirm wieder prüfbar ist.

Kernaussage: Eine Erwartung taugt nur, wenn der Ausführende prüfen kann, ob sie eingetreten ist. Meist ist das der Bildschirm. Wo der Bildschirm nicht reicht, muss die Deklaration sagen, wo man stattdessen nachsieht, hier in der Datenbank.

Was ein Testfall-Review leistet und was nicht

Am 29. August, demselben Tag wie der zweite Fall, stand ein dritter Testfall vor seinem ersten Lauf. An ihm lässt sich ablesen, wie weit man ohne Ausführung kommt.

Die Vorgeschichte: Ein Fehler in einem Dialog der Anwendung war behoben. Er trat nur bei Spalten auf, die schon einmal ausgewählt und wieder abgewählt worden waren. Der Agent hatte den Fix mit zwölf automatisierten Tests abgesichert, und ein Prüfdurchgang mit elf Prüfpunkten hatte ihn abgenommen. Im Browser durchklicken konnte dieser Prüfdurchgang nicht, weil in seiner Umgebung die Anmeldung fehlte. Stattdessen schrieb er den Klickweg als manuellen Testfall auf und meldete den Fehler als behoben und bereit zum Schließen.

Der Maintainer fragte zurück, ob nicht erst der Testfall laufen müsse, bevor der Fehler geschlossen wird. Die Suche über alle acht Lauf-Protokolle, die es bis dahin gab, ergab: Der Testfall war geschrieben, in der Übersicht geführt und aus dem Fehler verlinkt, aber nie ausgeführt. Der Fehler wäre auf Grundlage von Tests und Prüfdurchgang geschlossen worden, und niemandem wäre es aufgefallen, weil nichts danach fragt.

Bevor geklickt wurde, prüfte der Agent den Testfall am Code. Die entscheidende Frage: Stellen die ersten Schritte des Testfalls überhaupt den Zustand her, in dem der Fehler auftritt, also eine Spalte, die einmal ausgewählt und wieder abgewählt war? Am Code ließ sich das bestätigen. Der Testfall war also richtig gebaut.

Dann lief er zum ersten Mal, und der Lauf fand trotzdem zwei Fehler in der Deklaration. Schritt 4 erwartete beim Abwählen einen Bestätigungs-Dialog. Der kam nicht, und das war richtig so: Die Anwendung fragt nur nach, wenn beim Abwählen etwas mitgelöscht würde. Die Erwartung stammte aus einer Dokumentation, die den Dialog pauschal erwähnt, die genaue Bedingung stand nur im Code. Schritt 6 verlangte, im Auswahlfeld eine Markierung „NEU“ an der Spalte zu sehen. Die gibt es, aber nur im aufgeklappten Feld vor dem Klick: Mit dem Auswählen wird die Spalte übernommen, und die Markierung verschwindet im selben Moment. Der Schritt beschrieb eine Beobachtung an der falschen Stelle.

Kernaussage: Ein Testfall-Review gegen den Code beantwortet, ob ein Zustand herstellbar ist. Ob eine Erwartung am Bildschirm sichtbar ist, und in welchem Moment, beantwortet es nur zum Teil. In diesem Fall zeigte es erst die Ausführung. Ein nie gelaufener Testfall ist deshalb ein Entwurf, auch wenn er gut gebaut ist.

Der Gesamtlauf: 16 von 30

Vom 13. bis zum 15. September 2026 lief der Katalog zum ersten Mal vollständig: 30 aktive Testfälle in fünf Suiten, ein Protokoll je Suite, in der lokalen Entwicklungsumgebung. Der Maintainer klickt. Der Agent leitet an, liest parallel einen Mitschnitt der Datenbank mit, der alle zwei Sekunden die Zählerstände der Anwendung festhält, und schreibt das Protokoll. Alle 30 Testfälle endeten grün, zwei erst nach einem Fix.

Der Lauf fand 19 Fehler in der Anwendung, jeder als eigener Eintrag in der Fehlerliste des Projekts festgehalten und inzwischen behoben, von einer falschen Sortierung bis zu einem Deaktivieren, das Einstellungen einer anderen Tabelle mitlöschte. Nur zwei davon fanden die Testfälle auf die vorgesehene Art, weil ein Schritt nicht das erwartete Ergebnis brachte. Die übrigen 17 fielen beim Ausführen nebenbei auf: weil während eines Testfalls etwas passierte, das kein Schritt abfragte, beim Herstellen der Ausgangslage, beim Aufräumen danach, beim erneuten Prüfen eines gerade behobenen Fehlers oder weil der Agent vor einem Testfall den Code las und dabei etwas sah.

Die Zahl, um die es hier geht, ist eine andere: In 16 der 30 Testfall-Dateien wurde während des Laufs etwas geändert. Als Fehlerquote taugt die Zahl nicht ohne Weiteres. Die Praxis war drei Wochen alt, und nicht jede Änderung behebt einen Fehler. Sortiert man die 16 Dateien nach dem Anlass ihrer ersten Korrektur, ergeben sich vier Gruppen:

  • Die Anwendung hatte sich seit der Deklaration geändert (sechs Dateien): Ein späterer Fix hatte einen Button entfernt, eine Reihenfolge gesperrt oder eine Anzeige ergänzt, und die Deklaration war nicht nachgezogen worden. Ein Testfall erledigte zwei Dinge in einer Reihenfolge, die die Anwendung seit einem Fix zwei Wochen zuvor nicht mehr zulässt.
  • Eine Vorbedingung, die kein Schritt herstellte (vier Dateien): Ein späterer Schritt setzte etwas voraus, das laut Vorbedingung nicht da war, oder er prüfte Werte, die kein Schritt gesetzt hatte. Zwei dieser Testfälle waren offenbar gegen einen Umgebungsstand geschrieben, in dem es schon da war.
  • Ein Schritt, der von Anfang an nicht zur Anwendung passte (drei Dateien): Ein Schritt setzte einen Filter, der in der Ausgangslage auf alle Zeilen zutrifft. Die Tabelle wäre leer gewesen, und das, was der Schritt prüfen sollte, gar nicht sichtbar. Ein anderer wollte einen Filter umschalten, während eine Zeile markiert war, und genau dann blendet die Anwendung die Filter aus.
  • Nachzug und Präzisierung aus dem Lauf (drei Dateien): Ein Fix im Lauf änderte, wie ein Testfall hinter sich aufräumt, und zwei Testfälle bekamen nach dem Lauf genauere Angaben zur Ausgangslage. Das ist Pflege, kein Defekt.

In 13 der 16 Dateien stand also etwas, das sich so nicht ausführen oder nicht prüfen ließ. Sechs davon hatte ein späterer Fix an der Anwendung überholt, ohne dass jemand die Deklaration nachzog: Ein Katalog altert mit jedem Fix.

Der Mechanismus ist genauer, als die Pointe im Titel vermuten lässt. Elf der 16 Dateien wurden zum ersten Mal korrigiert, bevor der Maintainer den ersten Klick des jeweiligen Testfalls machte: beim Lesen der Deklaration gegen Code und Datenbank. Fünf Dateien bekamen ihre Korrektur erst beim Ausführen oder danach. Drei der elf vorab korrigierten brauchten nach dem Lauf trotzdem eine zweite, etwa weil ein Fix im Lauf eine angezeigte Zahl geändert hatte. In einer Suite waren beide Deklarations-Fehler erst beim Ausführen sichtbar. Ein Schritt verlangte, auf etwas zu klicken, das der vorige Schritt gerade hatte verschwinden lassen. Und ein Testfall, der seit seiner Anlage nie gelaufen war, beschrieb ein Element, das seit einer späteren Änderung nicht mehr eindeutig war.

Am 16. September, während dieser Artikel entstand, wiederholte sich das Muster im Kleinen: Zwei am Mittag deklarierte Testfälle wurden am Abend beim Vorbereiten ihres ersten Laufs korrigiert.

Kernaussage: Der erste vollständige Lauf eines jungen Katalogs prüft zuerst die Testfälle. Das meiste davon findet die Vorbereitung, also das Lesen der Deklaration gegen Code und Datenbank vor dem Klick, hier elf von 16 Korrekturen. Was sie nicht findet, findet erst die Ausführung.

Ein „pass“ ist eine Behauptung

Der Gesamtlauf hat noch etwas gezeigt, das nicht die Deklaration betrifft, sondern das Protokoll. Ein Testfall prüft, dass eine Ansicht, die der Nutzer aufgeklappt hat, nach einer Neuberechnung aufgeklappt bleibt. Im Lauf vom 8. September stand dieser Schritt auf „pass“. Der Code war seitdem unverändert. Beim Lesen des Codes vor dem Klick fiel dem Agenten auf, dass die Neuberechnung den Zustand sehr wohl anfasst. Eine gezielte Gegenprobe des Maintainers bestätigte es: Die Ansicht klappte zu. Der Schritt war nie grün gewesen.

Die Erwartung hat eine Eigenschaft, die sie anfällig macht: Sie behauptet, dass sich nach einer Aktion etwas nicht ändert. Sieht die Ansicht nach dem Neuladen plausibel aus, wird so eine Erwartung leicht abgehakt, weil nichts Auffälliges passiert.

Zweimal im selben Lauf deckte eine gesammelte Rückmeldung „pass“ laut Mitschnitt nicht alle Schritte ab. Beim erneuten Prüfen eines Fehlers verlangte die Deklaration, dass sich die Zahl der Tabellen zwischen zwei Neuberechnungen ändert, und der Mitschnitt zeigte für diese Schritte keine Änderung. Beim erneuten Prüfen eines anderen Fehlers fehlte die englische Runde. Beide Runden wurden wiederholt.

Kernaussage: Ein „pass“ ist zunächst eine Zusage des Ausführenden. Zum Nachweis wird es erst mit dem Protokoll pro Schritt und dem Mitschnitt daneben. Im DI²-Projekt gilt seitdem: Fehlt ein Schritt, der etwas in der Datenbank ändern muss, im Mitschnitt, gilt er als nicht gelaufen. Und Erwartungen der Form „ändert sich nicht“ verdienen einen zweiten Blick.

Wenn der Testfall besteht und die Funktion trotzdem fällt

Zurück zum 29. August und zu dem Testfall, der nie gelaufen war. Sein erster Lauf bestand, nach den zwei Korrekturen an der Deklaration. Er prüfte, dass sich eine bestehende Prüfregel auf eine andere Spalte umziehen lässt, ein Weg, in den ein Fix, zwölf automatisierte Tests und elf Prüfpunkte geflossen waren. Beim dritten Klick sagte der Maintainer, was ihm dabei auffiel: Es fühlt sich falsch an, bei einer bestehenden Regel die Spalte zu wechseln. Fachlich ist eine Regel auf einer anderen Spalte eine andere Regel, und der Umweg, neu anlegen und die alte löschen, kostet fast nichts. Noch am selben Nachmittag wurde die Fähigkeit entfernt.

Der Testfall wurde nicht gelöscht, sondern zurückgezogen. Er steht weiter im Katalog, mit dem Status „Zurückgezogen“ und der Begründung im Kopf: warum der Weg nicht mehr existiert, welche Fehlerklasse über das Neuanlegen bestehen bleibt und welcher Nachfolge-Testfall sie seitdem prüft. Diese Begründung ist inzwischen die ausführlichste Fassung der Produkt-Entscheidung im ganzen Repository. Das Protokoll desselben Tages verweist auf den Testfall, und der Verweis läuft 24 Testfälle später noch ins Ziel. Der bestandene Lauf bleibt gültig: Er belegt den damaligen Stand, nicht den heutigen.

- **Status:** Zurückgezogen (Entscheidung 2026-08-29: Die Spalte einer bestehenden
  Regel lässt sich nicht mehr ändern. Eine Regel auf einer anderen Spalte ist fachlich
  eine andere Regel, und der Umweg „neu anlegen, alte löschen“ kostet fast nichts. Der
  hier geprüfte Umzug ist damit ein verbotener Weg. Die zugrunde liegende Fehlerklasse
  bleibt über das Neuanlegen erreichbar und wird dort vom Nachfolge-Testfall geprüft.
  Der bestandene Lauf vom 2026-08-29 bleibt als Beleg des damaligen Stands gültig.)

Man kann das als Versagen der Anforderungs-Phase lesen: Die Frage, ob es diesen Weg überhaupt braucht, gehört vor die Umsetzung. Das stimmt. Im DI²-Projekt ist der Testfall trotzdem die einzige Stelle im Prozess, an der jemand die Schritte eines Nutzers der Reihe nach tatsächlich vollzieht. Reviews lesen Diffs, Prüfdurchgänge prüfen Kriterien, Spezifikationen beschreiben Absichten. Keines dieser Formate erzeugt das Gefühl „das würde ich so nie tun“. Dafür muss man es tun, und der Testfall ist in diesem Prozess die letzte Gelegenheit dazu, bevor es ein Nutzer tut.

Kernaussage: Ein bestandener Testfall kann die Funktion kosten, die er prüft, weil erst beim Durchklicken jemand merkt, dass es den Weg nicht geben sollte. Ein früherer Klick hätte den Fix gespart. Zurückziehen statt löschen hält Protokolle und Begründung intakt.

Testfälle validieren heißt ausführen: fünf Konsequenzen

  • Einmal fahren, sobald es klickbar ist: Nicht erst am Ende der Kette, wenn Fix, Tests und Prüfdurchgang schon auf den Weg gerichtet sind. Je später der erste Lauf kommt, desto mehr Arbeit hängt schon an dem Weg, den er infrage stellt. Die Testpraxis kennt dafür den Dry Run, auf Deutsch Probelauf: einen Durchgang, der nur prüfen soll, ob sich die Testfälle so ausführen lassen, wie sie dastehen. Im DI²-Projekt gab es keinen getrennten Probelauf, der erste echte Lauf hat diese Arbeit mit erledigt.
  • Das Testfall-Review als eigenen Schritt anlegen: Vor dem Lauf die Deklaration gegen Code und Datenbank lesen. Ist die Vorbedingung herstellbar, ist jeder Schritt ausführbar, gibt es jeden Button noch? Das findet die meisten Defekte, bevor jemand klickt.
  • Deklaration und Ausführung getrennt halten: Wer deklariert, schreibt gegen den Umgebungsstand in seinem Kopf. Wer ausführt, hat den echten. Die Trennung ist der Grund, warum die Ausführung überhaupt etwas findet.
  • Das Protokoll pro Schritt führen, den Mitschnitt daneben: Ein gesammeltes „pass“ ist eine Zusage, das Protokoll macht daraus einen Nachweis. Ein Schritt, der etwas in der Datenbank ändern muss und im Mitschnitt fehlt, gilt als nicht gelaufen. Erwartungen der Form „ändert sich nicht“ verdienen einen zweiten Blick.
  • Zurückziehen statt löschen: Ein Testfall, dessen Funktion es nicht mehr gibt, bleibt mit Status und Begründung liegen. Protokolle verweisen auf ihn, und die Begründung wird dort gelesen, wo jemand wissen will, warum ein Weg verschwunden ist.

Was hier steht, gilt für deklarierte manuelle Testfälle. Für automatisierte Tests gilt eine verwandte Lehre mit einem anderen Mechanismus: Ein grüner Test mit Platzhaltern bestätigt die Annahme, die in den Platzhaltern steckt. Das ist Thema des Artikels Der grüne Test, der nichts beweist. Beide teilen den Kern: Eine Prüfung, die noch nie an der Wirklichkeit war, hat noch nichts geprüft.

Arbeits-Prompts als Beispiel

Die Sitzungen sind nicht versioniert. Die zwei Prompts hier sind aus den Lauf-Protokollen und Commit-Nachrichten rekonstruiert und keine Zitate. Sie zeigen, was der Maintainer verlangt hat, nicht wie der Agent es umgesetzt hat.

Vor dem Gesamtlauf ging es darum, die Vorbereitung zum eigenen Schritt zu machen:

Bevor die Suite läuft: Lies jede Deklaration gegen den aktuellen Code und die
Datenbank. Ist die Vorbedingung herstellbar, ist jeder Schritt ausführbar, ist
jede Erwartung am Bildschirm auch wirklich zu sehen? Abnahme: pro Testfall und
Schritt ja oder nein mit Grund. Korrekturen an der Deklaration vor dem ersten
Klick committen, damit das Protokoll die gefahrene Fassung nennt.

Der Agent hat die Korrekturen mit Begründung committet und im Protokoll festgehalten, welche Korrektur vor welchem Testfall lag. Ob sich jede Erwartung am Bildschirm auch wirklich sehen lässt, konnte er nur teilweise beantworten, und genau dort lagen die zwei Fehler, die erst beim Ausführen sichtbar wurden.

Während des Laufs ging es darum, was als Nachweis gilt:

Protokolliere pro Schritt, was du im Mitschnitt gesehen hast, nicht mein „pass“.
Fehlt ein Schritt, der etwas ändern muss, im Mitschnitt, gilt er als nicht
gelaufen, und die Runde wird wiederholt. Abnahme: Jedes „pass“ im Protokoll hat
einen Zeitstempel aus dem Mitschnitt neben sich.

Zweimal hat der Agent daraufhin eine Runde zurückgewiesen, weil der Mitschnitt die Schritte nicht zeigte. Beide Prompts formulieren, was geprüft werden soll und woran das Ergebnis abgenommen wird. Wie der Agent liest und was er mitschneidet, bleibt ihm überlassen.

Was am Ende trägt

Die erste Ausführung eines Testfalls prüft drei Dinge. Zuerst den Testfall: Gibt es den Weg, und kann man am Bildschirm sehen, ob das Erwartete passiert? Solange das offen ist, sagt ein Schritt über die Anwendung nichts. Dann die Anwendung, und das ist der Normalfall, für den der Testfall geschrieben wurde. Und manchmal die Anforderung: ob es den Weg überhaupt geben sollte.

Geprüft wirdWas dabei auffälltWas als Beleg bleibt
zuerst der Testfallein Weg, den es nicht gibt, oder eine Erwartung, die niemand prüfen kanndie korrigierte Deklaration
dann die Anwendungein Schritt ohne das erwartete Ergebnis, und vieles nebenbeidas Protokoll pro Schritt, mit dem Mitschnitt daneben
manchmal die Anforderungein Weg, den es nicht geben sollteder zurückgezogene Testfall mit seiner Begründung

Ein nie gelaufener Testfall ist ein Entwurf. Ein bestandener Lauf ist ein Beleg für den Stand, an dem er lief. Dazwischen liegt die eine Prüfung, die kein Lesen ersetzt: jemand mit der Datei neben dem Browser.

FAQ

Was ist ein Testfall wert, den noch nie jemand ausgeführt hat?

So viel wie ein Entwurf. Die Deklaration kann einen Weg beschreiben, der nicht existiert, oder eine Erwartung, die am Bildschirm niemand nachprüfen kann, und beides fällt beim Lesen nicht auf. Im DI²-Projekt wurden im ersten vollständigen Lauf 16 von 30 Testfall-Dateien geändert, 13 davon, weil sich etwas nicht so ausführen oder prüfen ließ, wie es dastand. Validiert ist ein Testfall frühestens nach seinem ersten Lauf, und auch dann nur für den Stand, an dem er lief.

Reicht ein Testfall-Review, um Testfälle zu validieren?

Nein, aber es ist der beste erste Schritt. Wer die Deklaration gegen den aktuellen Code und die Datenbank liest, findet Vorbedingungen ohne Schritt, seit einem Fix unausführbare Schritte und Filter, die eine Tabelle leeren. Im Gesamtlauf waren das elf von 16 Korrekturen. Ob man am Bildschirm sehen kann, was der Testfall erwartet, lässt sich am Code nur zum Teil ablesen. Verlässlich zeigt es die Ausführung.

Wann sollte man einen Testfall zum ersten Mal ausführen?

Sobald der Weg klickbar ist, nicht erst am Ende der Kette. In der Testpraxis heißt ein solcher früher Durchgang Dry Run oder Probelauf. Im DI²-Projekt stand ein Testfall vor dem Schließen eines Fehlers und war nie gelaufen. Sein erster Lauf fand zwei Fehler in der Deklaration und eine Produkt-Entscheidung, die den ganzen Weg überflüssig machte. Ein früherer Klick hätte den Fix gespart.

Was macht man mit einem Testfall, dessen Funktion es nicht mehr gibt?

Zurückziehen, nicht löschen. Der Testfall bleibt mit Status und Begründung im Katalog, weil Protokolle auf seine Nummer verweisen und weil die Begründung dort gelesen wird, wo jemand wissen will, warum ein Weg verschwunden ist. Sein letzter bestandener Lauf bleibt als Beleg für den damaligen Stand gültig. Bleibt die Fehlerklasse über einen anderen Weg erreichbar, bekommt sie einen Nachfolge-Testfall.

Ist ein bestandener Lauf ein Nachweis?

Nur für das, was tatsächlich beobachtet wurde. Ein „pass“ aus einem früheren Lauf war im DI²-Projekt falsch, weil eine Erwartung der Form „ändert sich nicht“ plausibel aussah, und zwei gesammelte Rückmeldungen deckten laut Datenbank-Mitschnitt nicht alle Schritte ab. Nachweis ist das Protokoll pro Schritt mit dem Mitschnitt daneben.

Verwandte Artikel

Übergeordnet:

Geschwister:

Kontrolle und Diagnose:

  • Die Kontroll-Schleife — die Station „Testfälle deklarieren“ in der wiederkehrenden Kontrolle, und der nie gelaufene Testfall als ihre Grenze.
  • Der Agent misst, wo der Mensch klickt — dieselbe Arbeitsteilung bei der Fehlersuche: Der Mensch klickt, der Agent misst, und ein Befund trägt erst mit einer Messung dahinter.