Playwright mit KI-Agenten — Cheat Sheet

Der Spickzettel zum agentischen Teil des Seminars Playwright mit KI-Agenten: Wer welche Aufgabe hat, woran man ein erzeugtes Ergebnis prüft und wo die Grenzen liegen. Das Testhandwerk darunter — Locators, Assertions, Fixtures, Parallelität, CI — steht auf einem eigenen Blatt: Playwright-Testhandwerk.

Maßgeblich ist die Originaldokumentation auf playwright.dev; dieses Blatt trifft eine Auswahl — die Raster, die Versionssprünge überleben.

Deterministisch trifft probabilistisch

Ebene	Eigenschaft
Testausführung	Deterministisch — gleicher Lauf, gleiches Ergebnis
Codeerzeugung	Probabilistisch — gleicher Auftrag, anderes Ergebnis
Konsequenz	Erzeugtes wird geprüft, Ausgeführtes wird gemessen
Grenze	Der Agent darf vorschlagen, nicht allein entscheiden

Deshalb steht am Ende jeder Agentenschleife ein Diff und ein Review, nie ein direkter Commit.

Modul: Einführung: Playwright und KI-gestütztes Test Engineering

Die drei Agenten

Agent	Eingabe	Ergebnis
Planner	Auftrag, Seed-Test, optional Anforderungen	Markdown-Testplan in `specs/`
Generator	geprüfter Plan	Testdateien unter `tests/`
Healer	ein fehlgeschlagener Test	Änderungsvorschlag oder übersprungener Test

npx playwright init-agents --loop=claude   # vscode | claude | codex | opencode

Der Planner erzeugt keinen Testcode — er erkundet und schreibt einen Plan. Erst der Generator überführt ihn. Nach einem Playwright-Update werden die Agentendefinitionen neu erzeugt, sonst passen Werkzeugnamen und Optionen nicht mehr.

Modul: Tests entdecken mit dem Planner-Agenten

Woher die Erwartung kommt

Quelle	Was sie liefert
Anforderungen und User Stories	Zweck und Akzeptanzkriterien
Fachbereich	Geschäftsregeln, die die Oberfläche nicht zeigt
Bestehende Tests	Bereits abgesicherte Erwartungen
Beobachtung durch den Agenten	Ist-Verhalten, unbewertet

Nur die ersten drei taugen als Test Oracle. Ohne sie schreibt der Agent den Ist-Zustand als Erwartung fest — samt der Fehler, die schon drinstecken.

Modul: Anwendungen mit KI erkunden

Fragen, die brauchbare Beobachtungen liefern

Frageform	Ergebnis
Welche Eingaben werden abgewiesen und wie	Negativfälle
Was sieht diese Rolle, was jene nicht	Berechtigungen
Welche Zustände sind gleichzeitig möglich	Zustandskonflikte
Wo hast du geraten statt beobachtet	Unsichere Annahmen

Die letzte Frage trennt Beobachtung von Erfindung — und wird fast nie gestellt. Je Beobachtung Schritt, Erwartung, tatsächliches Ergebnis und Belegstelle verlangen: Meldungstext, Statuscode oder Konsolenzeile.

Modul: Anwendungen mit KI erkunden

Prüfraster für ein Szenario im Plan

Frage	Warnsignal
Welche Regel sichert es ab	Nur Klickfolge, keine Aussage
Woher stammt die Erwartung	Aus der Oberfläche abgeschrieben
Welche Daten braucht es	Ein fester Datensatz aus der Datenbank
Was ist der Ausgangszustand	Setzt das Ergebnis des Vorgängers voraus
Wie oft steht es schon da	Dieselbe Regel mehrfach beschrieben

Was den Raster nicht besteht, wird im Plan korrigiert — nicht später im erzeugten Testcode, dort ist es ein Vielfaches an Arbeit.

Modul: Tests entdecken mit dem Planner-Agenten

Reviewraster für erzeugten Testcode

Prüfpunkt	Woran es scheitert
Locators	Struktur statt Rolle, generierte Klassennamen
Assertions	Nur sichtbar, statt Inhalt und Zustand
Überflüssiges	Klicks und Prüfungen ohne Bezug zur Aussage
Wartezeiten	Feste Pausen statt Web-first Assertions
Testdaten	Zufallswerte oder feste Datensätze der Datenbank
Abhängigkeiten	Setzt Zustand aus einem anderen Test voraus

Beobachtung	Bewertung
Ein Testname mit „und” darin	Zwei Aussagen, trennen
Zwanzig Schritte vor der ersten Assertion	Setup gehört in eine Fixture
Prüft nebenbei die Navigation mit	Fremde Aussage, streichen
Baut auf dem Vorgängertest auf	Nicht isoliert, Ausgangszustand fehlt

Ein erzeugter Test kann grün sein und trotzdem wertlos: Das Review prüft die Aussage, nicht die Lauffähigkeit. Reihenfolge: Testnamen, Assertions, Ausgangszustand, Abgleich mit dem Plan — dann erst ausführen.

Modul: Testcode erzeugen mit dem Generator-Agenten

Auftrag an einen Agenten

Kontext: specs/warenkorb.md, tests/seed.spec.ts, tests/fixtures.ts
Ziel:    tests/warenkorb.spec.ts, ein Test je Szenario
Regeln:  nur Rollen-Locators, keine festen Wartezeiten,
         keine neuen Hilfsdateien, Daten je Test eindeutig
Prüfe:   jede Assertion gegen die Erwartung im Plan

Kontext, Ziel, Einschränkungen — der dritte Teil fehlt fast immer, und dann erfindet der Agent Struktur. Der Auftrag gehört versioniert ins Repository, sonst weicht jeder Lauf vom vorigen ab.

Modul: Testcode erzeugen mit dem Generator-Agenten

Fehlklassen vor dem Reparieren

Klasse	Richtige Reaktion
Geänderte Oberfläche oder Locator	Locator anpassen, Aussage behalten
Timing und Synchronisation	Web-first Assertion statt fester Pause
Testdaten oder Umgebung	Daten oder Setup reparieren, nicht den Test
Echte Regression	Test bleibt rot, Fehler ins Produkt melden
Veraltete Erwartung	Anforderung klären, dann Plan und Test ändern

Nur die ersten beiden Klassen rechtfertigen eine automatische Reparatur. Bei einer echten Regression ist der rote Test das gewünschte Ergebnis.

Modul: Fehlgeschlagene Tests sicher reparieren

Guardrails fürs Healing

Änderung	Bewertung
Locator auf Rolle umstellen	Erlaubt
Feste Pause durch Assertion ersetzen	Erlaubt
Erwarteten Wert an das Ist anpassen	Nur mit fachlicher Klärung
Assertion entfernen	Nicht erlaubt
Test überspringen	Nur mit Ticket und Frist
Testnamen ändern	Nicht erlaubt — daran hängt die Historie

Diese Tabelle gehört in die Agentendefinition, nicht nur in den Kopf der Reviewerin. Ein übersprungener Test sieht im Report aus wie ein bestandener Lauf.

Modul: Fehlgeschlagene Tests sicher reparieren

MCP oder CLI

Kriterium	MCP	`playwright-cli`
Erkundung	Sehr gut geeignet	Gut geeignet
Lange, zustandsbehaftete Schleifen	Stärke	Über Sessions möglich
Kontextverbrauch	Eher höher	Token-effizient
Integration	Strukturierte Werkzeuge	Shell und Skills
Große Repositories	Möglich	Besonders geeignet

npm install -g @playwright/cli@latest
playwright-cli install --skills
playwright-cli -s=shop open <url> --persistent
playwright-cli -s=shop snapshot        # Element-Referenzen
playwright-cli state-save zustand.json # angemeldeter Ausgangszustand

Kein Umschalter, sondern zwei Interaktionsmodelle auf demselben Browser. Beide arbeiten auf dem Accessibility Snapshot — Rollen, Namen, Referenzen statt Pixel.

Modul: Playwright MCP oder CLI

Sicherheit

Risiko	Gegenmittel
Beliebige JavaScript-Ausführung	Werkzeug aus, gilt als RCE-äquivalent
Prompt-Injektion über Seiteninhalte	Nur bekannte Umgebungen, Ausgaben prüfen
Abfluss von Zugangsdaten	Testkonten, Werte aus der Umgebung
Unbemerkte Änderungen am Repository	Alles über Pull Request und Review
Zugriff auf fremde Hosts	Erlaubte Ursprünge einschränken

Playwright nennt die MCP-Funktion zur Ausführung beliebigen JavaScripts ausdrücklich RCE-äquivalent — nur für vertrauenswürdige Clients. Storage-State-Dateien sind Anmeldedaten in Dateiform: nie committen.

Modul: Playwright MCP oder CLI

Abnahme eines agentengestützten Laufs

Kriterium	Nachweis
Jede Regel hat einen Test	Plan verweist auf Testnamen
Suite läuft parallel grün	Mehrere Läufe mit vier Workern
Keine stillen Übersprünge	Report ohne unerklärte `skipped`-Einträge
Reparaturen begründet	Fehlerklasse je Patch im Pull Request
Lücken dokumentiert	Liste offener Szenarien mit Begründung

Die letzte Zeile ist die wichtigste: Eine ehrliche Lückenliste ist mehr wert als eine geschönte Abdeckung.

Modul: Der agentengestützte Test-Workflow in der Praxis

Typische Fallen

Den Agenten als Ersatz für Teststrategie verstehen statt als Werkzeug.
Grüne Tests für Qualität halten, ohne die Assertions gelesen zu haben.
Vollständigkeit annehmen, weil der Plan lang ist — Länge ist bei Sprachmodellen keine Währung.
Halluzinierte Erwartungen übernehmen, weil sie fachlich klingen.
Den Plan direkt an den Generator geben, ohne ihn gelesen zu haben.
Die ganze Suite auf einmal heilen lassen und einen Diff erzeugen, den niemand liest.
Änderungen übernehmen, ohne die Ursache benennen zu können.
Übersprungene Tests nicht zählen und die Abdeckung überschätzen.
Lücken finden und nicht dokumentieren — ein halbes Jahr später hält sie jemand für abgedeckt.

Dieses Thema als Schulung für Ihr Team

Dieser Beitrag erklärt das Thema. Damit Ihr Team es danach auch anwendet, gibt es Playwright mit KI-Agenten als Schulung — an Ihrem eigenen Code, mit den Fragen, die ein Text nicht beantwortet. Sie wählen die Module, wir bauen daraus ein Programm.

4 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung

Als Team-Schulung anfragen Zum Seminar Playwright mit KI-Agenten →