Drei Playwright-Agenten: Planner, Generator und Healer in einer Live-Einkaufswagen-App

Die meisten Menschen haben die Demo gesehen: Ein Modell wird angesprochen, ein Playwright-Skript erhalten, einmal ausgeführt – und schon kurz darauf bricht es zusammen. Ein funktionierendes QA-Team folgt einem anderen Ablauf aus Erkunden, Planen, Automatisieren und Warten, und das Ziel hier war es, jedem dieser Schritte eine eigene Verantwortungseinheit zuzuweisen. Das Ergebnis ist ein wiederverwendbares Playwright-Framework, das von drei spezialisierten Agenten unterstützt wird:

• Planner erkundet die Live-Anwendung und erstellt den Testplan.
• Generator wandelt ein einzelnes geplantes Szenario in eine funktionierende Testspezifikation um.
• Healer führt die Testsuite aus, ermittelt die Ursachen für fehlgeschlagene Tests und behebt diese.

Das Demo-Ziel war eine kleine Warenkorb-App mit einem Ablauf von der Anmeldung über die Produktansicht, den Warenkorb, die Zahlung bis hin zur Dankesseite. Es entstanden insgesamt 22 automatisierte Szenarien, die erfolgreiche Abläufe, negative Fälle sowie Validierungsedge-Cases abdeckten. Sie laufen parallel und nutzen Seite-Objekte, die von den Agenten selbst verwaltet werden. Der Playwright-HTML-Bericht zeigte 22 bestandene Tests, 0 fehlgeschlagene Tests und 0 instabile Tests; die gesamte Testreihe wurde in 16,2 Sekunden abgeschlossen.

Vorbereitungen vor dem Start jedes Agenten

Zuerst müssen drei Dinge vorhanden sein. Die meisten Anleitungen überspringen sie, doch sie bestimmen, ob die erzeugten Ergebnisse überhaupt nutzbar sind.

Playwrights MCP-Testserver. Die Agenten sollten nicht im Unklaren über den DOM sein, daher werden echte Browser verwendet. Eine Konfigurationsdatei verbindet sie miteinander:

{
  "servers": {
    "playwright-test": {
      "type": "stdio",
      "command": "npx",
      "args": ["playwright", "run-test-mcp-server"]
    }
  }
}

Dies stellt jedem Agenten Werkzeuge wie browser_navigate, browser_snapshot und browser_click zur Verfügung, sowie test_run und test_debug für den Healer.

Ein Framework-Vertrag. Eine Datei namens framework.md legt die Verzeichnisse und Konventionen fest: Selektoren gehören in pages/, Benutzerprozesse in flows/ und Adressen sowie Anmeldeinformationen in .env. Jeder Agent liest diese Datei vor dem Ausführen von Aktionen, sodass die Ergebnisse wie eine einzige Codebasis aussehen und nicht wie drei unterschiedliche persönliche Stile.

Ein Starttest. Eine sehr kleine Spezifikation öffnet die eigentliche Startseite und überprüft etwas Stabiles. Jeder generierte Test beginnt von diesem bekannten, funktionierenden Zustand aus.

Ein Agent ist nur so gut wie die Grundlagen, auf denen er läuft – und diese drei bilden genau diese Grundlagen.

Der Planer: Entscheidung darüber, was getestet werden sollte

Der Planner schreibt überhaupt keinen Code. Er öffnet die Anwendung, bewegt sich wie ein neugieriger Tester darin umher und kartiert das Vorhandene: Formulare, Authentifizierung, den Warenkorb, die Zahlungsschritte, Validierungsmitteilungen sowie leere Zustände.

Ihre Routine:

1. Rufen Sie einmal planner_setup_page auf.
2. Erkunden Sie die Anwendung mit den Browser-Tools und lesen Sie DOM-Snapsshots anstelle von Screenshots.
3. Identifizieren Sie die wichtigsten Abläufe sowie die möglichen Fehlerquellen für jeden davon.
4. Speichern Sie einen Markdown-Plan unter specs/-plan.md.

Jedes Szenario im Plan enthält einen Titel, nummerierte Schritte, ein erwartetes Ergebnis, eine Annahme bezüglich des Ausgangszustands (eine neue Sitzung, sofern nicht anders angegeben) sowie den Dateipfad, unter dem der Plan gespeichert wird.

Der Checkout-Plan umfasste insgesamt 22 Szenarien in Abschnitten für Anmelden, Warenkorb, Checkout sowie einen vollständigen End-to-End-Prozess. Diese Struktur bringt später Vorteile, denn der Generator wandelt jeden Abschnittsnamen in einen test.describe-Block um, wodurch Plan und Code von vornherein übereinstimmen.

Warum eine separate Phase? Die Abdeckung ist ein Denkproblem – wenn man gleichzeitig planen und kodieren muss, verschlechtert sich die Planung. Eine rein planerische Ausgabe kann bereits vor dem Entstehen einer einzigen Testzeile überprüft und geändert werden.

Der Generator: Ein Szenario in die Realität umsetzen

Der Generator bearbeitet jeweils nur ein Szenario nach dem anderen, niemals den gesamten Plan. Für jedes Szenario führt er folgende Schritte aus:

1. Führt generator_setup_page aus, um den Ausgangszustand zu erreichen.
2. Führt jeden Schritt direkt im Browser aus und betrachtet den Schrittext als Anweisung.

Liest den Ausführungsprotokoll mit generator_read_log zurück, das die tatsächlich funktionierenden Lokatoren enthält.

Ruft generator_write_test auf, um eine einzelne Spezifikationsdatei zu erzeugen.

In Schritt drei stammt der Wert. Von den Trainingsdaten wird nichts gespeichert. Was in der Datei landet, ist ein Protokoll einer gerade abgeschlossenen Sitzung gegen die echte Schnittstelle.

Die Ausgabe befolgt automatisch die Regeln des Frameworks:

// spec: specs/checkout-e2e-plan.md
// seed: tests/web/seed.spec.js

import { test, expect } from '../../../fixtures';
import { users } from '../../../testdata';test.describe.configure({ mode: 'parallel' });test.describe('E2E checkout journey', () => {
  test('positive: login → add product → checkout → thank you → home', async ({ flow }) => {
    await flow.completeHappyPathPurchase();
  });
});

Ausgeblieben sind insbesondere CSS-Selektoren, ein echtes Passwort sowie URL-Strings. Die Selektoren werden in Seite-Objekte verschoben, und mehrstufige Abläufe werden zu Methoden in einer Flow-Klasse:

async completeHappyPathPurchase(user = users.standard, info = checkout.valid) {
  await this.goToCheckoutInformation(user);
  await this.fillValidInformation(info);
  await this.continueToOverview();
  await this.app.checkoutOverview.expectProductVisible(products.first.name);
  await this.finishOrder();
  await this.backHomeToProducts();
}

Jeder Test erhält durch die Fixtures außerdem seinen eigenen Browser-Context, sein eigenes Page-Object-Graph sowie seine eigene Flow-Instanz. Da es keinen gemeinsamen, veränderbaren Zustand gibt, ist das Testsuite von Anfang an parallelisierbar – und nicht erst als Nachgedanke hinzugefügt. Das unterscheidet ein Skript von einem Framework.

Der Heiler: Die richtige Schicht beheben

Die Erstellung von Tests ist ein einmaliger Vorteil. Die Wartung hingegen stellt die dauerhaften Kosten dar – und genau hier kommt der dritte Agent ins Spiel. Sein Ablauf ist wie folgt:

1. test_run führt die Suite aus und sammelt Fehler ein.
2. test_debug stoppt bei jedem Fehler.
3. Er prüft den aktuellen Snapshot, die Konsole, den Netzwerkverkehr sowie die fehlerhafte Assertion.
4. Er diagnostiziert die Ursache: einen geänderten Locator, eine veränderte Timing-Struktur, ein geänderter Vertrag oder einen echten Produktfehler.

Es behebt die Ursache und nicht nur das Symptom, indem es pages/ aktualisiert, wenn sich die Benutzeroberfläche verschiebt, und api/endpoints/, wenn sich ein Vertrag verschiebt.

Dann wird dieser Test erneut ausgeführt und mit dem nächsten Fehler fortgefahren.

Zwei Sicherheitsmechanismen sorgen dafür, dass das System zuverlässig bleibt. Es schwächt niemals eine Prüfung, nur um einen erfolgreichen Ausführungsergebnis zu erzielen. Wenn das Produkt fehlerhaft ist und der Test korrekt, markiert es den Test mit test.fixme() sowie einem Kommentar, der das tatsächliche Verhalten beschreibt, sodass der Fehler sichtbar bleibt und nicht übersehen wird. Zudem werden unzuverlässige APIs wie networkidle als Lösung für Ressourcenkonflikte vermieden.

Der Vorteil besteht in der Konzentration von Änderungen. Wenn man einen Button umbenennt, wird nur eine Methode des Seitenobjekts geändert, wodurch alle Tests, die dieses Objekt verwenden, wieder funktionieren. Da 22 Tests insgesamt 325 Zeilen an Seitenobjekten in 10 Klassen nutzen, führt eine Neugestaltung nicht dazu, dass der gesamte Testumfang zusammenbricht. Insgesamt hat jeder Entwickler einen klaren Verantwortungsbereich im Repository, und die gemeinsam genutzte Schicht der Seitenobjekte hält das gesamte System zusammen.

Von Anfang bis Ende ausführen

Die Einrichtungsbefehle:

1. Copy .env.example → .env, set BASE_URL (+ credentials)
2. npm install && npx playwright install

Und der Agent führt nacheinander aus:

3. Run the Planner
      → specs/checkout-e2e-plan.md   (22 scenarios, reviewed by me)4. Run the Generator, scenario by scenario
      → tests/web/login/login.spec.js
      → tests/web/cart/cart.spec.js
      → tests/web/checkout/checkout.spec.js
      → tests/web/e2e/checkout-journey.spec.js5. npm test        (4 workers, fully parallel)6. Any red? Run the Healer → re-run → green

Der Wechsel zu einem anderen Produkt beeinflusst die Agenten nicht. Setzen Sie BASE_URL auf das neue Produkt, erstellen Sie die Seitenobjekte und Testdaten erneut und geben Sie anschließend wieder die gleichen drei Befehle ein. Da die Agenten framework.md und .env lesen anstelle eines fest kodierten Produktnamens, ist der Pipeline portabel und nicht speziell angepasst.

Wie viel schneller ist es wirklich?

Eine Behauptung wie „KI macht es zehnmal schneller“ sollte ohne detaillierte Aufschlüsselung nicht akzeptiert werden. Das Manuell-Schreiben eines End-to-End-Tests dreht sich selten um das Eintippen. Stattdessen muss man DevTools öffnen, nach einem stabilen Selektor suchen, die Schaltfläche in einem ungewöhnlichen Wrapper finden, den Test erneut ausführen, um zu prüfen, ob die Überprüfung zu früh ausgelöst wird, und von vorn anfangen. Der größte Aufwand entsteht in diesem Entdeckungsprozess, und der Generator übernimmt dies, indem er die Schritte live ausführt und mitteilt, was funktioniert hat.

Die Vorteile zeigen sich in mehreren Phasen:

• Beschlussfindung bezüglich des Abdeckungsumfangs. Manuell ist dies ad hoc und übersieht oft negative Fälle. Der Planner listet im Voraus positive, negative sowie Randfälle auf.
• Auffinden von Lokatoren. Das manuelle Suchen in den DevTools nach einzelnen Elementen wird durch Lokatoren ersetzt, die aus einer bereits abgeschlossenen Sitzung gewonnen werden.
• Erster erfolgreicher Test. Der Zyklus von Schreiben, Ausführen, Beheben und Wiederholen wird durch Generierung anhand eines überprüften Transkripts ersetzt.
• Aufrechterhaltung der Testsuite. Das Durchsuchen jeder Spezifikation nach fehlerhaften Selektoren wird durch eine einzige Korrektur des Page-Objects ersetzt, die alle abhängigen Tests behebt.

Die größten Einsparungen ergeben sich bei den zweiten bis zwanzigsten Test. Der erste Test verursacht echte Aufwände für Page-Objects, Fixtures sowie die Ausgangsdaten. Ab dann besteht ein neuer Szenario meist aus dem Zusammenstellen bestehender Bestandteile, wodurch die Kosten pro Test schnell sinken.

Die Ausführungsgeschwindigkeit stammt von einem völlig anderen Ort. Parallelismus ist keine Eigenschaft künstlicher Intelligenz – es handelt sich dabei um eine Gestaltungsregel, die die Agenten befolgen müssen. Jeder Test erhält einen neuen Kontext aus den Fixtures, und keiner verändert den Zustand des gemeinsamen Moduls; daher läuft die Konfiguration vollständig parallel: vier Worker lokal, zwei im CI mit zwei Wiederholungsversuchen, wobei Spuren und Videos nur bei Testfehlern aufgezeichnet werden. Jede Suite, die eine Login-Sitzung wiederverwendet, kann ohne Risiko nicht auf diese Weise laufen. Diese hingegen schon, denn die Regel „Ein Szenario entspricht einem unabhängigen Test“ musste der Generator in jeder Datei befolgen.

Vier Lektionen, die man übernehmen kann

• Halten Sie die Rollen eng gefasst. Ein einziger umfassender Prompt, der planen, kodieren und debuggen soll, führt zu unklaren Ergebnissen. Drei fokussierte Rollen, jede mit ihren eigenen Werkzeugen, hinterlassen in jeder Phase etwas, das überprüft werden kann.

Vertrauen auf Ausführung über den Speicher. In einem laufenden Browser bestätigte Lokatoren sind zuverlässiger als solche, die aus Dokumentationen geschätzt werden.

Bauen Sie das Gerüst vor den Agenten. Seite-Objekte, Fixtures, Umgebungsverwaltung und parallele Regeln sorgen dafür, dass die KI-Ausgabe ein Framework und nicht nur eine Ansammlung von Skripten ist. Das Schreiben von framework.md verbesserte die Qualität mehr als jede Anpassung der Anweisungen.

Wiederherstellung ist das eigentliche Ergebnis. Ein Test einmal zu erstellen ist einfach. Ein Agent, der nach einem UI-Update weiterhin 22 Tests bestehen lässt, rechtfertigt die Anwendung dieses Ansatzes.

Wer davon profitiert

QA-Engineer, die mehr Zeit damit verbringen, Lokatoren zu reparieren, anstatt Testabdeckung zu entwickeln, werden davon profitieren. Ebenso Teams, die Playwright einführen möchten und KI innerhalb einer strukturierten Rahmenbedingung nutzen wollen, anstatt sie durch etwas anderes zu ersetzen, sowie alle, die Copilot- oder Cursor-Agenten mit Playwrights MCP-Testserver vergleichen.

Nichts davon ersetzt die QA-Arbeit. Die Entscheidung darüber, was wichtig ist, was als echter Fehler gilt und welche Testabdeckung fehlt, bleibt beim Menschen. Die Agenten übernehmen das Erkunden, die Standardaufgaben sowie den mühsamen Reparaturprozess – also das Planen, Erstellen, Ausführen, Beheben und erneute Ausführen des Tests.