Abnahmetests mit Playwright MCP: Agenten durchlaufen die Journeys

Was Abnahmetests mit Playwright MCP hier leisten

Agentengesteuerte Abnahmetests sind ein Prüf-Loop, in dem ein KI-Agent jede User Journey in einem echten Browser durchläuft und anhand eingefrorener Abnahmekriterien meldet, ob sie bestanden ist oder nicht. API- und MCP-Journeys laufen genauso ab, als echte Aufrufe gegen die laufende App.

Ein Test, den der bauende Agent für sich selbst schreibt, beweist nichts. Wir wollen ein Urteil von einem Agenten, der nur die Kriterien liest und das Produkt bedient. Nachdem Claude Code ein Feature gebaut hat, geht ein zweiter Agent jede Journey mit Playwright MCP durch und hält jede entscheidende Beobachtung per Screenshot fest. ConvOps steuert die Schritte, die Gates und den Fix-Loop. Er ist einer der Loops, mit denen wir unser Unternehmen führen.

Alle Beispiele nutzen Quillbay, eine fiktive Buchungs-App für Töpferstudios, und ihre neue Warteliste für ausgebuchte Kurse.

Die Kriterien werden zuerst eingefroren; ein Fehlschlag geht zurück in einen Fix, und der ganze Lauf wiederholt sich.

Warum wir ihn gebaut haben: grüne Ebenen, kaputte Journeys

Grüne Unit-Tests sagen Ihnen, dass die Teile funktionieren. Ob eine Person ihre Aufgabe auf dem Bildschirm zu Ende bringen kann, sagen sie nicht.

Vor diesem Loop bestand jede untere Ebene: Unit-Tests, Phasen-Reviews, die Regressionssuite in der Merge-Pipeline. Dann scheiterte der erste agentengesteuerte Lauf der Journeys gegen die echte App trotzdem an einem großen Teil davon. Die Fehler lagen zwischen den Ebenen: ein Link, den ein Service erzeugt und ein anderer liest, eine Weiterleitung, die einen Parameter verlor. Keine Ebene war für die Nahtstelle zuständig, also fing keine sie ab.

Daraus entstanden zwei Überzeugungen. Wer baut, kann nicht urteilen, deshalb schreibt und repariert der Tester nie Code. Und nur ein Lauf gegen die echte App beweist ein Kriterium.

Wenn die Features Ihrer Agenten jede Prüfung bestehen und auf dem Bildschirm trotzdem kaputtgehen, sehen Sie sich an, wie ConvOps einen Plan von eingefrorenen Kriterien bis zum verifizierten Build führt(wird in einem neuen Tab geöffnet).

So läuft es: sechs Schritte und vier Agenten

Die Reihenfolge der Schritte ist die Absicherung. Die Kriterien werden eingefroren, bevor Code existiert, die Umgebung ist nachweislich grün, bevor der Tester ankommt, und die Entscheidung trifft jemand, der den Fix nicht geschrieben hat.

Claude Code baut das Feature zwischen Schritt 2 und 3.

Kriterien schreiben. Jedes Kriterium nennt einen Akteur, ein Verhalten und etwas, das man beobachten kann: einen Bildschirm, eine Meldung, eine Antwort. „Code ist vorhanden“ ist nie ein Kriterium, denn was man nicht beobachten kann, kann man nicht abnehmen. Die Freigabe friert die Liste ein: Spätere Schritte fügen keines hinzu, streichen keines und deuten keines um.

Journeys planen. Eine Journey pro Kriterium, das wörtlich zitiert und mit seiner ID genannt wird, sodass jedes Kriterium genau eine Stelle hat, an der es bewiesen wird.

Umgebung vorbereiten. Ein eigener Infrastruktur-Agent startet die Branch-Umgebung des Plans, stellt Daten und Credentials über den Mechanismus des Plans bereit und hält sie fest. Das Gate hängt am Grün, nicht am Aufwand. Der Tester bereitet nichts vor, also kann er nicht bestehen, indem er sich einen leichten Fall selbst baut.

Ausführen, entscheiden, beheben. Der Abnahmetester durchläuft die Journeys und repariert nie etwas. Ein Fehlschlag schickt den Bericht an den Entwickler-Agenten, der die Fixes auf demselben Branch committet, und der ganze Plan läuft erneut.

Der Loop hat keinen Timer: Er läuft nach dem Build jedes Plans und bei einem Task immer dann, wenn sich eine Journey geändert hat. Ein Lauf auf Task-Ebene leitet 3 bis 8 Journeys ab: den Happy Path plus den riskantesten Fehlerpfad je geändertem Verhalten. Überspringen ist nur erlaubt, wenn es keine Journey zu durchlaufen gibt (ein reines Refactoring, Tooling, Doku, Konfiguration oder reine Teständerungen), und der Grund wird genannt. Im Zweifel wird ausgeführt.

Microsofts Playwright Test Agents(wird in einem neuen Tab geöffnet) (Planner, Generator, Healer) erzeugen und reparieren Testcode. Unsere Agenten erzeugen aus eingefrorenen Anforderungen einen Plan und einen Bericht mit Urteilen. Die Gates funktionieren wie in So bauen wir ein selbstverbesserndes KI-System, und die Freigaben sind Human-in-the-Loop-Gates.

Vier Agenten planen, bereiten vor, testen und beheben; eine Person gibt die Kriterien frei und liest jeden Bericht.

Ein Lauf Schritt für Schritt: die Quillbay-Warteliste

Der spannende Moment ist nicht das erste FAIL. Es ist der erneute Lauf nach dem Fix, denn der Entscheidungsschritt akzeptiert keinen anderen Beweis.

Auslöser. Die Build-Schritte von plan/waitlist sind abgeschlossen. Die Kriterien FR-1 bis FR-4 wurden eingefroren, bevor es Code gab.

Der Plan. Journey U2 nennt FR-2 und zitiert es: „Wird ein Platz frei, erhält die erste Person auf der Warteliste eine E-Mail, deren Link den Kurs öffnet, wobei der Platz 2 Stunden lang reserviert bleibt.“ Jede Vorbedingung sagt, wie man sie bestätigt: Der Kurs acc-wl-r7-class-wheel-basics ist mit 8 von 8 Plätzen ausgebucht (die Seite zeigt „Full“ ausgebucht und die Schaltfläche „Join waitlist“ auf die Warteliste), beide Teilnehmer können sich bei Quillbay anmelden, und ausgehende Mails landen im Capture-Postfach.

Jede Journey zitiert ihr Kriterium wörtlich und nennt seine ID.

Vorbereiten. Der Infrastruktur-Agent weist nach, dass wl-waitlist.app.quillbay.example.com und die zugehörige API grün sind, und hält die Teilnehmer-Fixtures und den Schlüssel der Studioinhaberin zur Wiederverwendung fest.

Lauf 1. Der Abnahmetester durchläuft vier Journeys bei 1440x900 und prüft layoutrelevante Bildschirme noch einmal bei 390x844.

Empfehlung: FIX REQUIRED. U2 ist eine Nahtstelle: API und App bestehen jeweils ihre Unit-Tests, und nur die Journey führt durch beide.

Entscheiden. Eine Person gibt den Bericht frei, und die Entscheidung lautet: nicht bestanden. U2 betrifft Code, den dieser Plan ausgeliefert hat, also wird er auf dem Branch behoben und nicht als Ticket abgelegt.

Beheben. Der Entwickler-Agent reproduziert U2 in derselben Umgebung, ändert den Link, führt den Unit-Test für die geänderte Datei aus und committet fix(waitlist): email link uses the class id (4c1e9a7) auf plan/waitlist. Der Infrastruktur-Agent richtet das Mail-Capture ein.

Lauf 2. Der ganze Plan läuft erneut: alle vier Journeys, nicht nur U2 und U3. Alle bestehen, und der Screenshot von U2 zeigt „Seat held for you for 2 hours“ (Ihr Platz ist 2 Stunden für Sie reserviert). Empfehlung: PROCEED. Die Entscheidung lautet: bestanden, und der Bericht fließt in den Verifikationsabschnitt des Merge-Requests ein.

Der Fix zählt erst, wenn der ganze Plan erneut gelaufen ist und jede Journey besteht.

So sieht der Bericht aus, und so lesen Sie ihn

Lesen Sie BLOCKED vor FAIL. Eine Journey, die niemand durchlaufen konnte, verbirgt am ehesten einen echten Fehler.

Unsere Pläne enthalten noch eine Regel: Ein Schritt, der eine undokumentierte Voraussetzung, einen zweiten Versuch oder eine manuelle Nachbesserung brauchte, ist ein FAIL, auch wenn das Verhalten am Ende funktioniert hat. Was nur mit Hilfe besteht, besteht für Nutzer nicht. Und ein PASS, dessen Screenshot das geprüfte Element nicht zeigt, ist kein Beleg: Wer das Urteil abnimmt, öffnet die Bilder.

Lesen Sie zuerst den Kopfbereich und die BLOCKED-Zeilen: Sie zeigen, was der Lauf nicht testen konnte.

Was schiefgeht: Nahtstellen, für die keine Ebene zuständig war

Die meisten unserer Abnahmefehler waren keine Bugs, die das Modell übersehen hat. Es waren Nahtstellen zwischen Ebenen, für die keine Ebene zuständig war.

Der wichtigste Fall hat die Form von Quillbays U2: Ein erster Abnahmelauf scheitert an einem großen Teil der Journeys, während jede untere Ebene grün ist, und jeder Fehler liegt zwischen den Ebenen. Die Regel daraus: Abnahmetests in einer echten Umgebung laufen lassen, bevor die Review-Schritte teuer werden, und für jeden Plan mit UI-, API- und MCP-Oberfläche einen zweiten vollständigen Lauf einplanen.

Jede Ebene bestand für sich; die Fehler lagen dazwischen, wo nur eine Journey hindurchführt.

Finden und Beheben als getrennte Jobs ist auch das Rückgrat unseres Loops für die selbstheilende Website.

Selbst bauen: die Anweisungen, die jeder Agent erhält

Beginnen Sie mit den Kriterien und der Regel „nie reparieren“. Playwright MCP ist der einfache Teil. Der Tester dient der Verifikation, nicht der Fehlersuche: Erst debuggen, dann die Abnahmetests einmal laufen lassen, sobald Sie glauben, dass der Build funktioniert. Die Schritte unten geben die Reihenfolge vor; hier sind die Anweisungen zum Kopieren.

Testplaner: die Journey-Vorlage.

Für jedes eingefrorene Kriterium EINE Journey schreiben:
  ID: U<n> (UI) oder A<n> (API/MCP)
  Kriterium: <FR id>, wörtlich zitiert
  Vorbedingungen: jeweils mit „So bestätigen“.
    Eine fehlende ist ein Blocker, kein Workaround.
  Schritte: nummeriert; jeder nennt, was beobachtet wird.
  Viewports: 1440x900; jeden layoutrelevanten Bildschirm
    bei 390x844 erneut prüfen.
  Fixtures: Präfix acc-<plan>-<run>-; nach dem Lauf aufräumen.
Jede Journey mit dem abgleichen, was die Umgebung
tatsächlich kann.

Infrastruktur-Agent: vorbereiten und prüfen.

Die Branch-Umgebung des Plans vorbereiten, dann nachweisen,
dass sie grün ist.
1. Jeden Service starten, den der Plan berührt. Alle müssen laufen.
2. Daten und Credentials NUR über den Mechanismus des Plans
   bereitstellen. Kein Mechanismus: anhalten und nachfragen.
   Die Credentials für den Tester festhalten.
3. Prüfen:
   - Health liefert 200
   - ein ECHTER Daten-Endpoint liefert 2xx, nicht nur Health
   - Aufruf ohne Authentifizierung: 401/403; mit: 2xx
     (MCP: tools/list UND ein authentifizierter Tool-Aufruf)
   - 3-5 zentrale Seiten per Playwright: keine Konsolenfehler,
     keine fehlgeschlagenen Requests, keine leeren Bildschirme
   - der Hauptablauf funktioniert einmal von Anfang bis Ende
4. Beheben, was rot ist, erneut prüfen, nur bei Grün weiter.
   Produktfehler mit Fundstelle und Beleg melden.
Die Journeys nicht ausführen. Nichts abbauen.

Abnahmetester: ausführen und berichten.

Die Umgebung ist vorbereitet und läuft. Die festgehaltenen
Credentials wiederverwenden. Nichts starten oder abbauen.
Jede UI-Journey mit Playwright MCP ausführen, jede
API/MCP-Journey mit echten Aufrufen, danach die
Regressions-Checkliste.
Dem Plan der Reihe nach folgen. Nie Code reparieren. Nie
einen Fehlschlag überspringen. Keine improvisierten Tests.
Jede Beobachtung, die über einen Schritt entscheidet, per
Screenshot festhalten. API-Antworttexte protokollieren.
Urteil pro Journey: PASS, PARTIAL PASS, FAIL, BLOCKED,
COVERED BY SUITE.
Bericht: Kopfbereich; Pflichtangaben im Kopfbereich (was
nicht getestet werden konnte, jeweils benannt);
Journey-Ergebnisse; Fehlschläge im Detail (Schritt, erwartet,
tatsächlich, Beleg, empfohlener Fix); Regressions-Checkliste;
Empfehlung: PROCEED oder FIX REQUIRED.

Entscheidungsregel.

PASS nur, wenn jede Journey PASS ist oder eine akzeptierte
Ausnahme: ein Fehlschlag in Code, den diese Änderung nicht
ausgeliefert hat, als eigenes Ticket erfasst und per ID zitiert.
Alles andere ist FAIL: den Bericht an den Fix schicken, dann
den GANZEN Plan erneut ausführen.
Ein Fehlschlag in Code, den diese Änderung ausgeliefert hat,
wird auf dem Branch behoben, nie als eigenes Ticket abgelegt.
Unklar, ob ein Verhalten beabsichtigt ist? Eine Person entscheidet.

Entwickler-Agent: beheben.

Für jede fehlgeschlagene Journey: in derselben Umgebung
reproduzieren, die Ursache finden, beheben, die Journey
live erneut durchlaufen.
Nur beheben, was die Fehlschläge erfordern. Keine
Kleinigkeiten, kein Aufräumen.
Unit- und Lint-Checks nur für die geänderten Dateien ausführen.
Auf demselben Branch committen. Festhalten, was sich geändert
hat und warum.
Nie den eigenen Fix bestätigen: Der erneute Lauf ist der Beweis.

Diese Ebene ersetzt keine CI: Unit-, Integrations- und Regressionstests bleiben das deterministische Gate in der Merge-Pipeline.

Kopieren Sie diese Anweisungen und fügen Sie die Abnahmeschritte dann in ConvOps zu Ihrem Workflow hinzu(wird in einem neuen Tab geöffnet).