Jeder, der mit Testautomatisierung arbeitet, kennt das Problem: Ein Button bekommt eine neue CSS-Klasse, die Seitenstruktur verschiebt sich leicht, ein Locator passt nicht mehr – und plötzlich schlagen Tests fehl, die gestern noch grün waren. Die Suche nach dem Fehler kostet Zeit, die eigentlich für neue Features gebraucht würde.
Genau hier setzt der Healer Agent an – der dritte im Bunde der Playwright Test Agents. Er soll fehlschlagende Tests automatisch erkennen, analysieren und reparieren. In diesem Tutorial prüfe ich, ob er hält, was er verspricht: einen echten Gamechanger für die Testautomatisierung – oder bleibt es doch nur ein spannendes Experiment? : )
Was ist der Healer Agent – und wie funktioniert er?
Der Healer Agent ist der dritte und letzte Agent im Playwright-System. Während der Planner Agent die Anwendung erkundet und der Generator Agent daraus Tests schreibt, übernimmt der Healer die Wartung: Er führt die Test-Suite aus und repariert fehlschlagende Tests automatisch.
Was den Healer dabei von klassischen Retry-Mechanismen unterscheidet: Er arbeitet nicht blind. Stattdessen analysiert er bei einem Fehler den Accessibility Tree der Seite und vergleicht ihn mit dem fehlgeschlagenen Locator. Daraus leitet er den korrekten Selector ab, passt den Test an und führt ihn erneut aus, um die Reparatur zu bestätigen.
Das Ergebnis ist laut offizieller Dokumentation entweder ein bestandener Test – oder, wenn der Agent die Funktionalität für grundlegend kaputt hält, ein als übersprungen markierter Test. Der Healer entscheidet also in gewisser Weise, wann ein Problem für ihn zu groß ist, um es automatisch zu lösen.
Der Playwright Healer. Quelle: https://playwright.dev/docs/test-agents
Das Testszenario: Absichtlich einen Locator kaputt machen
Als Testobjekt verwende ich SauceDemo – denselben Demo-Onlineshop, den ich bereits in den letzten Tutorials verwendet habe. Konkret nehme ich den Testfall für den erfolgreichen Login, den ich mit dem Generator Agent erstellt hatte.
Um den Healer Agent in Aktion zu sehen, mache ich den Test zunächst absichtlich kaputt: Ich verfälsche den Locator für das Username-Feld, indem ich einen Tippfehler einbaue. Der Test schlägt danach erwartungsgemäß fehl – der Locator findet das Element nicht mehr.
npx playwright test tests/login.spec.ts
Der Healer Agent in Aktion: Szenario 1 – falscher Locator
Ich wechsle in den GitHub Copilot Chat, wähle den Healer Agent aus und gebe eine einfache Anweisung:
Bitte heile meinen Test login.spec.ts
Der Agent analysiert den fehlgeschlagenen Test, inspiziert den Accessibility Tree der Login-Seite und gibt die Antwort zurück: Er hat den Tippfehler im Selector erkannt und korrigiert – und zusätzlich eine Assertion leicht robuster gemacht. Die Datei wird direkt aktualisiert.
Ein kurzer Blick in die Datei bestätigt: Der Locator ist wieder korrekt. Der Test läuft erneut durch – und ist erfolgreich.
Szenario 2: Falsche Credentials im Negativtest
Im zweiten Szenario gehe ich einen Schritt weiter. Ich verfälsche nicht den Locator, sondern die Testlogik selbst: Im Negativtest für ungültige Anmeldedaten trage ich absichtlich die korrekten Credentials ein.
Der Test schlägt fehl, weil der Login nun erfolgreich ist – was dem erwarteten Verhalten (Fehlermeldung) widerspricht.
Ich gebe dem Healer Agent die Anweisung:
Bitte heile meinen Testfall invalid-login.spec.ts
Auch hier liefert der Agent eine überzeugende Antwort: Er erkennt, dass die Credentials falsch gesetzt wurden, tauscht sie gegen die erwarteten ungültigen Zugangsdaten aus und bestätigt die Reparatur. Der Test läuft erneut erfolgreich durch.
Was kann der Healer Agent – und wo liegen seine Grenzen?
Stärken:
Intelligente Fehleranalyse: Der Agent liest DOM, Locators, Konsolen-Logs und Netzwerk-Requests – nicht nur die Fehlermeldung
Selbstverifikation: Er führt den reparierten Test direkt aus und bestätigt, dass die Lösung funktioniert
Wartungsersparnis: Teams, die 30–40 % ihrer Sprint-Zeit mit dem Reparieren von Locators verbringen, können hier deutlich Zeit sparen
Kontextverständnis: Er erkennt nicht nur Tippfehler, sondern auch logische Fehler wie falsche Testdaten
Grenzen:
Locator-Ebene: Der Healer ist stark bei Selector- und UI-Änderungen – bei tiefgreifenden Logikfehlern in der Anwendung selbst kommt er laut vielen Quellen im Netz noch an seine Grenzen. Ich werde hierzu zeitnah weitere Versuche starten.
Auth-Flows: Bei Tests hinter einem Login muss die Session vorab eingerichtet sein
Kein Ersatz für Review: Die vorgenommenen Änderungen sollten natürlich immer manuell geprüft werden – der Agent könnte Symptome beheben, ohne die Ursache zu verstehen
VS Code-Abhängigkeit: Der Agent läuft aktuell am zuverlässigsten im VS Code Agent Mode
Fazit: Ein Mehrwert für die Testautomatisierung
Der Healer Agent hat mich in diesem Tutorial beeindruckt. Beide Szenarien – der fehlerhafte Locator und die falschen Credentials – wurden schnell und korrekt repariert, ohne dass ich selbst debuggen musste.
Ist das jetzt ein Gamechanger? Für Teams mit großen, dynamischen Test-Suites und häufigen UI-Änderungen: ja, definitiv ist er bereits eine große Bereicherung. Der Healer Agent kann einen erheblichen Teil der repetitiven Wartungsarbeit übernehmen und gibt QA Engineers mehr Zeit für strategische Aufgaben.
Zusammen mit dem Planner und Generator Agent entsteht von Playwright nun ein geschlossener Workflow bereit: Planung → Generierung → automatische Wartung. Genau das ist die Vision hinter den Playwright Test Agents – und der Healer ist der Baustein, der diesen Kreis schließt.
