Tests entdecken mit dem Planner-Agenten

Tests entdecken mit dem Planner-Agenten

0:00 Playwright bringt seit einiger Zeit eigene Agenten mit — nicht als Plugin von irgendwoher, sondern als Teil des Werkzeugs. Drei Stück sind es: Planner, Generator und Healer. In diesem Modul geht es um den ersten, und er ist der angenehmste, weil sein Ergebnis kein Code ist, sondern ein Text, über den man streiten kann. Genau das ist der Trick: Der fachliche Streit findet auf einer Ebene statt, die alle im Team lesen können — bevor auch nur eine Zeile Testcode entsteht.

Playwright-Agenten ins Projekt holen

0:28 Zuerst die Mechanik: Wie kommen diese Agenten überhaupt ins Projekt, was legen sie dort ab, und was bedeutet das für Ihr Repository? Ein Befehl, ein paar Dateien — und danach liegen drei Agenten in Ihrem Repository. Was genau dort entsteht, sollten Sie wissen, denn es bestimmt, was diese Agenten dürfen. Die Arbeitsteilung ist klar geschnitten und lohnt sich zu merken. Der Planner erkundet die Anwendung und schreibt einen Testplan in Markdown.

0:55 Der Generator macht daraus Playwright-Tests. Der Healer führt die Suite aus und repariert, was fehlschlägt. Erzeugt werden die drei einmalig im Projekt — als Textdateien mit Anweisungen und erlaubten Werkzeugen. Wichtig ist der erste Punkt: Der Planner schreibt keinen Testcode. Diese Verwechslung führt regelmäßig zu Enttäuschung, dabei ist die Trennung der eigentliche Gewinn.

1:18 Ein Befehl, vier Varianten. Der sogenannte Loop bestimmt, für welchen Coding Agent die Definitionen geschrieben werden — für VS Code, Claude Code, Codex oder OpenCode. Das Format unterscheidet sich, der Ablauf dahinter ist derselbe. Nehmen Sie den Loop, der zu Ihrem Werkzeug passt, nicht den, den die Kollegin gestern benutzt hat; sonst findet der Agent seine Werkzeuge nicht.

1:40 Der Befehl legt Dateien im Projekt an — schauen Sie sich den Diff danach in Ruhe an, es lohnt sich. Dort steht schwarz auf weiß, was diese Agenten dürfen. Diese vier Orte sind ab jetzt Ihre Landkarte. Die Agentendefinitionen sind Anweisungen und Werkzeuglisten — sie gehören ins Review wie jeder andere Code, denn sie bestimmen das Verhalten.

2:01 Der Ordner für Testpläne ist bewusst ein eigener: Pläne sind Dokumente für Menschen, keine Testartefakte. Im Testordner landen die erzeugten Dateien, und der Seed-Test ist der Startpunkt, über den wir gleich ausführlich sprechen. Wenn Sie sich eine Sache merken: Alles davon ist versioniert. Ein Agent, dessen Regeln nur auf einem Laptop liegen, verhält sich in jedem Team anders.

2:24 Ein unscheinbarer, aber praktisch wichtiger Punkt. Die Definitionen beschreiben Werkzeuge und Abläufe einer bestimmten Playwright-Version. Nach einem Versionswechsel passen Namen und Optionen nicht mehr zwangsläufig — und der Agent scheitert dann auf eine Weise, die niemand sofort mit dem Update in Verbindung bringt. Deshalb: nach Updates neu erzeugen. Sichern Sie vorher Ihre eigenen Ergänzungen, denn die gehen dabei verloren.

2:49 Und lesen Sie den Diff danach; er zeigt Ihnen, was sich am Verhalten der Agenten geändert hat — eine Information, die Sie sonst nirgends bekommen. Vier typische Anfängerfehler. Die Definitionen von Hand umzuschreiben ist verlockend und wird beim nächsten Erzeugen bestraft — Ergänzungen gehören an eine Stelle, die Sie kontrollieren.

3:08 Den falschen Loop zu wählen kostet eine frustrierende Stunde. Die erzeugten Ordner nicht zu committen bedeutet, dass jeder im Team mit anderen Agenten arbeitet, ohne es zu merken. Und nach einem Update zu rätseln, warum plötzlich nichts mehr geht, ist der Klassiker, den wir gerade besprochen haben.

Kontext für den Planner vorbereiten

3:26 Jetzt zum Teil, der über die Qualität des Ergebnisses entscheidet — und der gleichzeitig am häufigsten übersprungen wird: die Vorbereitung. Dieser Teil wird gern als Formalität behandelt und entscheidet in Wahrheit über die Qualität des Ergebnisses. Zwei Dinge braucht der Planner unbedingt, und eines davon ist ein ganz gewöhnlicher Test.

3:45 Der Planner erwartet dreierlei: einen klaren Auftrag, einen Seed-Test und, wenn vorhanden, ein Anforderungsdokument. Der Seed-Test ist der interessante Teil. Er ist ein lauffähiger Test, der die Umgebung herstellt — er meldet an, legt Grunddaten an und landet dort, wo die Erkundung beginnen soll. Man kann ihn sich vorstellen wie den Hausschlüssel plus Wegbeschreibung, den Sie einem Handwerker geben.

4:08 Der Planner darf ihn ausführen und übernimmt damit Setup, Fixtures und Anwendungskontext, ohne sich das alles selbst zusammenzusuchen. Sieben Zeilen, die nichts Fachliches prüfen — und das ist Absicht. Der Test beweist nur, dass die Umgebung steht und der angemeldete Zustand erreichbar ist. Beachten Sie, woher die Zugangsdaten kommen: aus der Umgebung, nicht aus dem Repository.

4:31 Das ist kein Formalismus, sondern die Regel, die verhindert, dass Passwörter über Git in fremde Hände geraten — und in Modul sieben werden wir sehen, dass ein browsersteuernder Agent diese Disziplin doppelt braucht. Der Seed-Test ist übrigens auch für Menschen nützlich: Er scheitert als Erster, wenn die Umgebung kaputt ist.

4:50 Der Auftrag folgt demselben Muster wie in Modul drei, nur präziser. Anwendung und Startadresse nennen. Den Ausschnitt begrenzen — welche Reise, welche Rolle, welche Grenzen. Auf den Seed-Test verweisen und ihn ausführen lassen. Vorhandene Anforderungen als Datei mitgeben statt als Fließtext im Prompt; Dateien kann der Agent gezielt nachschlagen, Fließtext verdrängt nur Kontext.

5:14 Und zuletzt das gewünschte Ergebnis benennen: ein Plan mit Schritten, Erwartung und Testdaten. Ohne diese letzte Angabe bekommen Sie eine Aufzählung, mit ihr ein Dokument. Vier Wenn-dann-Sätze, die man sich einrahmen kann. Ohne Seed-Test verbringt der Planner die Erkundung mit der Anmeldung — Sie zahlen also für einen Login.

5:34 Ohne Grenzen wandert er in Bereiche, die niemand testen wollte. Ohne Anforderungen schreibt er den Ist-Zustand fest, das kennen wir aus dem Vorgängermodul. Und ohne festen Ablageort landen Pläne verstreut, und dann pflegt sie niemand. Der gemeinsame Nenner: Fast alles, was an einer Agentenschleife schiefgeht, entscheidet sich vor ihrem Start.

Testpläne erzeugen und prüfen

5:55 Jetzt lassen wir den Planner arbeiten — und danach kommt der Teil, der die eigentliche Wertschöpfung ausmacht: das Prüfen dessen, was er abliefert. Jetzt kommt das erste Artefakt, über das ein ganzes Team reden kann — auch die Kolleginnen, die keinen Testcode lesen. Genau darin liegt sein Wert. Wir schauen uns an, wie so ein Plan aussieht und mit welchem Raster man ihn durchgeht.

6:17 Das Ergebnis ist eine Markdown-Datei mit Szenarien: Schritte, erwartetes Ergebnis, benötigte Testdaten. Bewusst menschenlesbar, und das ist kein Zugeständnis an Nichttechniker, sondern der Kern der Idee. Auf dieser Ebene kann die Fachabteilung widersprechen, ohne Testcode lesen zu müssen. Ein Fehler im Plan kostet fünf Minuten, derselbe Fehler in fünfzehn erzeugten Testdateien kostet einen Nachmittag.

6:41 Sehen Sie den Plan deshalb als das, was er ist: ein Vorschlag zur Diskussion, nicht als Zwischenschritt auf dem Weg zum Code. Fünf Durchgänge, und der erste ist der wichtigste: Prüfen Sie je Szenario, welche fachliche Aussage darin steckt. Sehr oft steht dort nur eine Klickfolge — das sieht aus wie ein Testfall, behauptet aber nichts. Zweitens: Erwartungen gegen die Anforderung halten, nicht gegen die Oberfläche.

7:07 Drittens Duplikate zusammenführen, die dieselbe Regel absichern. Viertens fehlende Negativfälle und Rollen ergänzen und als Lücke kennzeichnen. Und fünftens priorisieren — nach Risiko, nicht nach Reihenfolge. Was Sie zurückstellen, wird ausdrücklich zurückgestellt, nicht stillschweigend vergessen. Die rechte Spalte ist als Warnsignal-Liste gebaut, und jedes dieser Signale kennen Sie inzwischen. Eine Klickfolge ohne Aussage.

7:34 Eine Erwartung, die aus der Oberfläche abgeschrieben wurde. Ein fester Datensatz aus der Datenbank, der spätestens beim parallelen Lauf kollidiert. Ein Ausgangszustand, der das Ergebnis des Vorgängers voraussetzt. Und dieselbe Regel, dreimal beschrieben. Wichtig ist, was mit einem Treffer passiert: Er wird im Plan korrigiert.

7:55 Nicht später im erzeugten Testcode — dort ist es fünfmal so viel Arbeit. Ihre Aufgabe: Nehmen Sie den erzeugten Plan, prüfen Sie ihn gegen die Anforderungen und überarbeiten Sie ihn begründet. Am Ende soll jedes Szenario eine Regel nennen, eine Erwartung und die Testdaten, die es braucht. Und noch etwas: Begründen Sie Ihre Streichungen.

8:16 Ein gestrichenes Szenario ist ein Ergebnis Ihrer Arbeit, kein Versäumnis — es dokumentiert eine Entscheidung. Wer das ein paarmal gemacht hat, merkt schnell, dass diese halbe Stunde die produktivste im ganzen Ablauf ist.

Grenzen automatischer Testfindung

8:30 Zum Abschluss der ehrliche Teil dieses Moduls. Was kann der Planner prinzipbedingt nicht finden — und was folgt daraus für Ihre Teststrategie? Zum Schluss die unbequeme Frage. Sie gehört dazu, denn ein Werkzeug einzusetzen heißt auch, seine Grenzen zu kennen und offen zu benennen. Vier Grenzen sind es, und keine davon verschwindet mit dem nächsten, besseren Modell.

8:52 Ein Planner erkundet sichtbares Verhalten. Alles, was sich nicht in der Oberfläche zeigt, bleibt ihm verborgen: Fristen, Freigaben, Berechnungen im Hintergrund, Zustände, die man nur über eine bestimmte Vorgeschichte erreicht. Ein erzeugter Testplan ist deshalb eine Inventur des Sichtbaren. Das ist wertvoll — eine solche Inventur von Hand zu erstellen, dauert Tage.

9:14 Aber es ist eben eine Bestandsaufnahme und noch keine Strategie. Der Unterschied ist derselbe wie zwischen einer Inventarliste und einer Versicherungspolice. Vier systematische Grenzen, und „systematisch" heißt: Ein besseres Modell ändert daran nichts. Implizite Geschäftsregeln ohne sichtbare Spur werden nicht entdeckt, weil es nichts zu entdecken gibt. Nicht erreichbare Zustände fehlen, weil der Weg dorthin unbekannt ist.

9:40 Rollenmodelle bleiben unvollständig, solange kein Zugang existiert. Und die vierte Grenze ist die unangenehmste: Halluzinierte Erwartungen. Sie klingen fachlich, sie klingen plausibel — und genau deshalb rutschen sie durch, wenn niemand gegen die Anforderung prüft. Der Vergleich in dieser Tabelle lässt sich auf einen Satz bringen: Der Plan listet, die Strategie entscheidet.

10:03 Ein erzeugter Plan gewichtet alle gefundenen Wege gleich, weil er keine Fehlerhistorie kennt und keinen Support-Kanal gelesen hat. Sie dagegen wissen, wo im letzten Jahr die Ausfälle waren und welche Regel Geld kostet, wenn sie bricht. Deshalb endet ein Plan mit einer Liste und eine Strategie mit einer Entscheidung. Das Gute daran: Beides zusammen ist deutlich mehr wert als jedes für sich — der Plan liefert das Material, das Sie sonst mühsam sammeln.

10:29 Vier Punkte zum Mitnehmen. Vollständigkeit anzunehmen, weil der Plan lang ist, ist die häufigste Fehleinschätzung — Länge ist bei Sprachmodellen keine Währung. Halluzinierte Erwartungen zu übernehmen passiert genau dann, wenn sie fachlich klingen. Den Plan direkt an den Generator zu geben, ohne ihn gelesen zu haben, spart zwanzig Minuten und kostet einen Tag.

10:50 Und Lücken nicht zu dokumentieren führt dazu, dass ein halbes Jahr später jemand glaubt, dieser Bereich sei abgedeckt. Im nächsten Modul wird aus dem geprüften Plan Testcode.