Der agentengestützte Test-Workflow in der Praxis

Der agentengestützte Test-Workflow in der Praxis

0:00 Zum Abschluss setzen wir alles zusammen. Elf Module lang haben wir einzelne Bausteine geübt — Erkundung, Planung, Erzeugung, Reparatur, Struktur, Parallelität, Pipeline. Jetzt läuft der ganze Ablauf einmal an einem zusammenhängenden Fall durch, von der Anforderung bis zum Pull Request. Sie werden merken: Die einzelnen Schritte sind Ihnen vertraut.

0:21 Die eigentliche Leistung liegt darin, sie in der richtigen Reihenfolge zu machen und an jeder Übergabe kurz innezuhalten.

Der Anwendungsfall und sein Fundament

0:29 Beginnen wir dort, wo jedes ordentliche Vorhaben beginnt — nicht beim Werkzeug, sondern bei der Frage, was eigentlich abgesichert werden soll. Es ist verlockend, bei einem Abschlussfall sofort den Planner zu starten. Wir machen es anders herum, und Sie werden merken, dass die Vorbereitung den ganzen Rest leichter macht.

0:47 Was hier entsteht, ist gleichzeitig die Vorlage für Ihr eigenes Projekt. Der Fall ist eine zusammenhängende Benutzerreise unseres Pflanzenversands: die Kasse mit Gutschein, in zwei Rollen und mit ihren Fehlerfällen. Das ist bewusst kein Spielzeugbeispiel — es hat eine Regel, die man in der Oberfläche nicht sehen kann, eine zweite Rolle mit anderer Sicht, und Fehlerfälle mit Meldungstexten.

1:10 Damit sind alle Schwierigkeiten drin, die wir einzeln behandelt haben. Der Fall durchläuft denselben Ablauf wie die Module — nur diesmal ohne Unterbrechung. Fünf Schritte, und alle passieren, bevor der erste Agent startet. Anforderungen und bekannte Regeln zur Kasse sammeln und aufschreiben. Risiken benennen und daraus den Auftrag ableiten. Einen Seed-Test schreiben, der angemeldet mit gefülltem Warenkorb landet.

1:36 Fixtures für beide Rollen bereitstellen, mit eindeutigen Daten je Test. Und die Grenzen festlegen: Umgebung, erlaubte Werkzeuge, verbotene Bereiche. Rechnen Sie mit einer halben Stunde. Diese halbe Stunde entscheidet über die Qualität von allem, was danach kommt. Diese Tabelle ist Ihr Auftrag auf einer Folie: Reise, Rollen, Fehlerfälle, Daten, Ergebnis.

1:58 Interessant ist die vierte Zeile — Daten werden je Test erzeugt, mit einer Kennung aus Worker und Test. Das ist keine Feinheit, sondern die Voraussetzung dafür, dass der Fall am Ende parallel läuft. Und die fünfte Zeile definiert, wann Sie fertig sind: nicht wenn die Tests grün sind, sondern wenn ein Pull Request steht, in dem jede Entscheidung nachvollziehbar ist.

2:20 Diese Festlegungen entstehen vor dem ersten Agentenlauf — sie sind der Maßstab. Vier Sätze, die Sie alle schon gehört haben — und die deshalb hier zusammenstehen. Ohne Anforderung schreibt der Planner den Ist-Zustand als Erwartung fest. Ohne Seed-Test verbringt er die Erkundung mit der Anmeldung. Ohne eigene Daten kollidieren die Tests, sobald sie parallel laufen.

2:42 Und ohne Grenzen wandern Änderungen in Dateien, die niemand angefragt hat. Wenn Sie aus diesem Seminar einen einzigen Satz mitnehmen, dann diesen: Fast alles, was an einer Agentenschleife schiefgeht, entscheidet sich vor ihrem Start.

Planen, erzeugen, reparieren

2:56 Jetzt die Schleife selbst — einmal vollständig, mit allem, was dazugehört. Und mit den Prüfschritten dazwischen, die den Unterschied machen. Sie kennen jeden einzelnen Schritt aus den Modulen vier bis sechs. Neu ist nur, dass sie diesmal ohne Pause ineinandergreifen — und dass Sie an jeder Nahtstelle selbst entscheiden, ob es weitergeht.

3:16 Der Ablauf lautet Planner, Generator, Healer. Was auf der Folie steht, ist allerdings das Entscheidende: Zwischen den Agenten steht jeweils ein menschlicher Prüfschritt. Der Plan wird fachlich überarbeitet, der erzeugte Code begutachtet, jede Reparatur klassifiziert und begründet. Man kann diese Schritte weglassen, dann läuft der Ablauf schneller — und liefert eine Suite, deren Wert niemand einschätzen kann.

3:40 Die Prüfschritte sind nicht der Preis für die Automatisierung, sie sind das, was sie brauchbar macht. Fünf Etappen. Planner beauftragen und den Plan gegen die Anforderungen überarbeiten. Generator beauftragen und den Diff vor dem ersten Lauf lesen. Dann — und das ist die Etappe, die man gern auslässt — Fehler und fragile Stellen gezielt provozieren.

4:02 Danach den Healer je Fehlschlag einzeln führen und die Fehlerklasse festhalten. Und zum Schluss in Fixtures und, wo es trägt, in Page Objects refaktorieren. Beachten Sie die Reihenfolge der letzten beiden Punkte: Erst stabilisieren, dann aufräumen. Nie umgekehrt. Drei Läufe, die Ihre Suite ärgern sollen. Der erste wiederholt jeden Test mehrfach mit vier Workern gleichzeitig — dabei fallen Datenkollisionen auf, bevor es die Pipeline tut.

4:29 Der zweite nimmt sich einen Bereich mit Trace-Aufzeichnung vor. Der dritte schließt die Quarantäne aus, damit das Ergebnis aussagekräftig bleibt. Der Gedanke dahinter ist einfach: Was diese drei Läufe übersteht, hält später auch dem CI-Lauf mit anderen Zeiten und weniger Ressourcen stand. Fehler, die Sie selbst provoziert haben, sind die billigsten.

4:50 Fünf Übergaben, fünf Fragen. Steht je Szenario eine fachliche Regel? Sind Datei, Umfang und Grenzen benannt? Sichern die Assertions die Aussage ab? Welche Fehlerklasse liegt vor? Blieb die Absicht des Tests unverändert? Diese Tabelle ist die Kurzfassung des ganzen Seminars, und die Fußnote sagt, warum sie zählt: Fällt ein Prüfschritt aus, wandert die Verantwortung stillschweigend zum Agenten.

5:15 Nicht durch eine Entscheidung, sondern durch Unterlassen — und genau das ist die Art von Verschiebung, die man erst bemerkt, wenn etwas passiert ist. Vier Fallen im großen Durchlauf. Alle drei Agenten hintereinander laufen zu lassen und erst am Ende hinzusehen, ist die Versuchung schlechthin — dann steht ein großer Diff da und niemand weiß, wo die Prüfung ansetzt.

5:37 Fehlschläge zu sammeln und in einem Rutsch heilen zu lassen, hebelt die Klassifikation aus. Zu refaktorieren, solange die Suite instabil ist, vermischt zwei Fehlerquellen. Und den Plan nach dem Generatorlauf nicht mehr zu pflegen, zerreißt die Kette, die Sie sich vorher aufgebaut haben.

Absichern, ausführen, übergeben

5:54 Bleibt der letzte Abschnitt: Wie wird aus einer grün laufenden Suite ein Ergebnis, das man jemandem übergeben kann? Hier trennt sich eine Übung von einer Arbeit, die man abgeben kann. Wir schauen uns an, was dafür fehlt, wenn die Tests bereits grün sind. Es sind vor allem drei Dinge, und keines davon ist aufwendig — sie werden nur gern vergessen, weil sie nach dem eigentlichen Erfolgserlebnis kommen.

6:17 Der Fall endet nicht mit grünen Tests. Er endet mit einem übergebbaren Ergebnis: einer parallel lauffähigen Suite, einem CI-Lauf mit archivierten Artefakten und einem Pull Request, in dem jede Entscheidung begründet ist. Der Unterschied ist derselbe wie zwischen „es funktioniert bei mir" und „es ist fertig". Und er ist in agentengestützter Arbeit wichtiger als früher, weil mehr Entscheidungen unterwegs getroffen wurden — von Ihnen und von den Agenten.

6:43 Wer sie nicht festhält, kann sie später nicht mehr rekonstruieren. Fünf Schritte zum Abschluss. Testdaten parallelisierbar machen und das mit mehreren Workern nachweisen. Die Suite über GitHub Actions ausführen und den Report als Artefakt sichern. Artefakte auswerten und offene Auffälligkeiten in den Plan zurückspielen — der Plan bleibt also lebendig.

7:05 Den Pull Request stellen, mit Plan, Tests, Reparaturen, Befunden und Lücken. Und im Review begründen, was nicht abgedeckt ist und warum. Der letzte Punkt fühlt sich unangenehm an und ist der professionellste des ganzen Ablaufs. Fünf Kriterien mit jeweils einem Nachweis — und das ist die eigentliche Botschaft dieser Tabelle: Jede Behauptung hat einen Beleg. Jede Regel hat einen Test, und der Plan zeigt es.

7:31 Die Suite läuft parallel grün, und mehrere Läufe zeigen es. Keine stillen Übersprünge, und der Report zeigt es. Reparaturen sind begründet, und die Fehlerklasse zeigt es. Und die letzte Zeile ist die wichtigste: Eine ehrliche Lückenliste ist mehr wert als eine geschönte Abdeckung — weil nur sie verhindert, dass jemand später auf eine Absicherung vertraut, die es nie gab.

7:53 Ihre Abschlussaufgabe: Führen Sie den agentengestützten Ablauf einmal eigenständig von der Anforderung bis zum Pull Request. Das Ergebnis enthält Plan, Tests, einen grünen CI-Lauf, begründete Reparaturen und die Lückenliste. Nehmen Sie sich Zeit für den letzten Punkt — er ist kein Anhängsel. Wer schneller fertig ist, ergänzt die zweite Rolle oder verteilt die Suite auf Shards. Und wenn unterwegs etwas nicht funktioniert: Das gehört dazu.

8:20 Der Umgang damit ist genau das, was wir geübt haben. Vier letzte Punkte. Die Lückenliste wegzulassen, weil sie unfertig wirkt, ist die häufigste Selbsttäuschung — sie wirkt nicht unfertig, sondern ehrlich. Den CI-Lauf erst am Ende einzurichten, bringt neue Fehler zum ungünstigsten Zeitpunkt; richten Sie ihn früh ein, auch mit wenigen Tests.

8:41 Reparaturen ohne Fehlerklasse zu übergeben, macht das Review blind. Und den Plan im Repository zurückzulassen, während die Tests weiterwandern, zerstört die Traceability, für die Sie so viel Mühe aufgewendet haben.

Danke!

8:55 Damit sind wir am Ende. Wenn Sie einen Gedanken mitnehmen, dann diesen: Der Ablauf trägt, solange an jeder Übergabe ein Mensch prüft. Die Agenten nehmen Ihnen das Tippen ab, das Erkunden, das erste Aufschreiben — und das ist viel. Was sie Ihnen nicht abnehmen, ist die Entscheidung, was richtig ist. Diese Aufgabe wird eher wichtiger, je besser die Werkzeuge werden. Materialien, Pläne und Beispiele liegen im Seminarrepository.

9:22 Vielen Dank für Ihre Aufmerksamkeit — und viel Erfolg beim Übertragen auf Ihre eigene Anwendung.