Playwright hat drei neue KI-Agenten vorgestellt – und ich möchte heute einen davon genauer unter die Lupe nehmen: den Planner Agent. Die Beschreibung auf der Playwright-Website klingt vielversprechend. Der Agent soll eine Webanwendung selbstständig erkunden, Benutzerflüsse analysieren und daraus einen strukturierten Testplan mit konkreten Szenarien ableiten.
Doch hält er, was er verspricht? Genau das ist die Frage, die ich mir in diesem Beitrag stelle: Kann der Planner Agent wirklich bei der Testplanung unterstützen – oder produziert er am Ende nur eine Liste offensichtlicher Testfälle?
Kurz: Was ist der Playwright Planner Agent?
Der Planner Agent ist einer von drei neuen Test Agents, die Playwright aktuell mitbringt. Jeder Agent übernimmt eine andere Rolle im Testprozess:
Der Planner Agent erkundet die Anwendung interaktiv und erstellt einen ausführlichen Testplan als Markdown-Dokument.
Der Generator Agent liest diesen Testplan und erzeugt daraus automatisch echte Playwright-Testdateien.
Der Healer Agent führt die Tests aus und repariert fehlschlagende Tests automatisch – ein interessanter Self-Healing-Ansatz.
Playwright’s drei AI Agents. Quelle: https://playwright.dev/docs/test-agents
In diesem Beitrag steht der Planner Agent im Mittelpunkt. Was kann er, wo liegen seine Grenzen – und wie holt man das Beste aus ihm heraus?
Installation: Schnell und unkompliziert
Die Installation war erfreulich einfach. Ein einziger Befehl im Projektverzeichnis reicht aus:
npx playwright init-agents --loop=vscode
Playwright richtet daraufhin automatisch alles ein: Agent-Dateien, eine MCP-Konfiguration und eine Seed-Datei – alles direkt abgestimmt auf Visual Studio Code und den GitHub Copilot Agent Mode.
Wer schon einmal manuell Testing-Infrastruktur aufgebaut hat, weiß, wie angenehm so ein reibungsloser Einstieg ist. : )
Was steckt im Planner Agent?
Nach der Installation findet man die Agent-Dateien unter:
.github/agents/
Ein Blick in die Planner-Agent-Datei zeigt zunächst eine generische Beschreibung sowie eine Liste der verfügbaren Tools. Was dabei sofort auffällt: Der Agent arbeitet nicht nur auf statischem HTML-Code. Er interagiert aktiv mit der Anwendung – klickt Buttons, füllt Formulare aus, navigiert durch Menüs – genau so, wie es ein echter Benutzer tun würde.
Das ist ein entscheidender Unterschied zu klassischen Code-Analyse-Tools. Der Planner Agent erlebt die Anwendung, anstatt sie nur zu lesen.
Konfiguration eines Playwright-Test-Planner-Agenten in VS Code mit Zugriff auf zahlreiche Browser-Automatisierungs-Tools über MCP. Eigene Darstellung.
Die Seed-Datei: Der Startpunkt für die Exploration
Neben den Agent-Dateien erstellt Playwright automatisch eine sogenannte Seed-Datei. Sie dient als Ausgangspunkt für die KI-gestützte Exploration und gibt dem Planner Agent einen ersten Browser-Kontext sowie eine grundlegende Teststruktur.
Die Seed-Datei eignet sich außerdem ideal als erster Smoke-Test, um das gesamte MCP- und Playwright-Setup schnell zu überprüfen. Ich habe den page.goto-Befehl so angepasst, dass die Zielanwendung direkt beim Start aufgerufen wird.
Was braucht der Planner Agent zum Starten?
Bevor es losgeht, noch ein wichtiger Hinweis. Der Planner Agent erwartet drei Dinge:
1. Einen Prompt als Startanweisung – z.B. „Generate a comprehensive test plan for the login page”
2. Die Seed-Datei als Einstiegspunkt in die Anwendung
3. Optional: ein Product Requirement Document (PRD) mit fachlichem Hintergrundwissen zur Anwendung, damit der Agent Geschäftsregeln und Anforderungen von Anfang an kennt
Das PRD ist optional, kann aber die Qualität des Testplans deutlich steigern – besonders bei komplexen Anwendungen.
Der Planner Agent in der Praxis: Login-Seite unter der Lupe
Als Testobjekt habe ich SauceDemo verwendet – einen Demo-Onlineshop mit typischen E-Commerce-Funktionen wie Login, Produktkatalog, Warenkorb und Checkout.
SauceDemo.com als Testobjekt. Quelle: https://www.saucedemo.com/
Ich habe mich bewusst auf die Login-Seite fokussiert, um den Agenten nicht zu überfordern und die Ergebnisse gut bewerten zu können.
Der verwendete Prompt war simpel:
Create a comprehensive test plan for the login page
Was danach passierte, hat mich wirklich überrascht. Der Agent hat die Seite eigenständig erkundet, die verfügbaren Eingabefelder analysiert und – ohne weiteres Zutun – einen Testplan mit 17 Szenarien erstellt. Und das waren keine generischen Platzhalter:
Beispiel 1: Erfolgreicher Login mit den korrekten Demo-Credentials (die der Agent selbst erkannt hat)
Beispiel 2: Negativszenarien mit ungültigen Benutzernamen und Passwörtern
Beispiel 3: Security-Aspekte wie SQL-Injection-Versuche im Login-Formular
Beispiel 4: Randfälle wie führende Leerzeichen und Case-Sensitivity bei der Passworteingabe
Für einen vollautomatisch generierten ersten Aufschlag ist das bemerkenswert gut. Vor allem die Security-Szenarien und Randfälle zeigen, dass der Agent nicht nur oberflächlich denkt.
Von der KI generierter Testplan für die Saucedemo-Loginseite mit definierten Testfällen, Erfolgskriterien und Fehlerbedingungen. Eigene Darstellung. Auch Security-Testfälle hat der Agent auf dem Schirm.
Was passiert bei einem offenen Prompt?
Neugierig geworden, habe ich im nächsten Schritt einen deutlich offeneren Prompt ausprobiert:
Please generate a test plan for our whole site
Das Ergebnis war überraschend – und ehrlich gesagt zwiegespalten. Statt eines einzelnen Testplans hat der Agent eigenständig eine komplette QA-Architektur aufgebaut: mehrere Markdown-Dateien mit Risikoanalyse, Teststrategie, Umfangsdefinition und sogar einer Testmatrix.
Einerseits: beeindruckend. Der Agent denkt wie ein QA Lead, strukturiert Risiken, priorisiert Module und denkt in Testebenen. Andererseits: Für eine kleine Demo-Anwendung ist das schlicht überdimensioniert. Vieles davon fühlt sich wie Dokumentationsoverhead an, den man im Projektalltag selten braucht.
Die Lektion daraus: Der Planner Agent folgt dem Prompt sehr wörtlich. Ein offener Prompt erzeugt ein offenes – und damit oft zu breites – Ergebnis. Ein Learning daraus: Wer einen fokussierten Testplan möchte, sollte den Scope im Prompt anfangs klar benennen.
Ein offener Prompt erzeugt auf Anhieb eine vollständige Testarchitektur. Eigene Darstellung. Ein offener Prompt erzeugt auf Anhieb eine vollständige Testarchitektur. Eigene Darstellung (2).
Tipps für bessere Ergebnisse mit dem Planner Agent
Aus meinen Experimenten habe ich ein paar praktische Erkenntnisse mitgenommen:
1. Scope eingrenzen: Lieber einen Prompt pro Feature oder Seite als einen Prompt für die gesamte Anwendung
2. PRD nutzen: Fachliche Anforderungen als Kontext mitzugeben verbessert die Qualität der Szenarien spürbar
3. Iterativ arbeiten: Testplan erstellen, prüfen, gezielt nachschärfen – der Agent versteht auch Follow-up-Prompts
4. Seed-Datei anpassen: Den richtigen Einstiegspunkt in die Anwendung zu setzen spart dem Agenten Zeit und verbessert die Exploration
Fazit: Mehr als eine Liste offensichtlicher Testfälle
Die Eingangsfrage war: Kann der Planner Agent wirklich bei der Testplanung helfen – oder produziert er nur offensichtliche Testfälle?
Meine Antwort: Er kann wirklich helfen. Mit einem präzisen Prompt und einem klaren Scope liefert der Playwright Planner Agent erstaunlich strukturierte und durchdachte Testpläne – inklusive Edge Cases und Security-Szenarien, die man sonst leicht übersieht.
Wo er an Grenzen stößt: Bei zu offenen Prompts neigt er dazu, eine vollständige Testarchitektur zu bauen, die für kleine Projekte zu komplex ist. Hier braucht es etwas Feingefühl beim Prompten.
Insgesamt ist der Planner Agent ein echter Mehrwert im Testing-Workflow – besonders in Kombination mit dem Generator- und Healer-Agent, die aus dem Plan direkt ausführbare und selbstheilende Tests machen. Diese werde ich nächste Woche im Tutorial ausführlich vorstellen. :- )
