Leipzig, 6. November 2026 – Ein Browser öffnet sich, eine Seite wird eingelesen, ein Test entsteht, läuft und wird nach dem Ergebnis verändert. Was nach einem kleinen digitalen Selbstläufer klingt, ist ein von iX am 5. November 2026 beschriebener Workflow für KI-gestützte Ende-zu-Ende-Tests mit Playwright, Claude Code und dem Model Context Protocol (MCP).

Der Agent arbeitet dabei nicht bloß eine starre Klickfolge ab. Claude Code öffnet die Webseite, liest ihre aktuelle Struktur, erzeugt Testcode, führt ihn aus und bessert nach, wenn etwas schiefgeht. Genau da liegt der Unterschied zu klassischen Recordern, die oft schnell starten, bei einer veränderten Oberfläche aber ebenso schnell ins Stolpern geraten. Ein neues Produkt, ein Release oder ein Preismodell ist das ausdrücklich nicht – beschrieben wird ein bestehender Workflow.

Drei Bausteine, ein Testablauf

Playwright steuert den Browser und führt die Aktionen aus. Claude Code fungiert als Coding-Agent: Er erzeugt, startet und verbessert den Testcode und entscheidet über die nächsten Schritte. MCP verbindet beide Systeme. Der Playwright-MCP-Server wird laut den Quellen von Microsoft bereitgestellt.

Der grundlegende Aufbau bleibt dabei nicht an Claude Code gebunden. MCP ist an keinen bestimmten Anbieter gekoppelt; auch ein Client wie Copilot CLI kann eingesetzt werden, sofern er MCP unterstützt. Für Puppeteer und Selenium gibt es ebenfalls MCP-Server. Die Auswahl von Playwright, Claude Code und MCP beruht im beschriebenen Beispiel auf den Erfahrungen des Autors.

Ende-zu-Ende-Tests betrachten eine Anwendung aus Sicht der Nutzerinnen und Nutzer: Webseite im Browser öffnen, festgelegte Schritte ausführen, erwartete und tatsächliche Ergebnisse vergleichen. Das kann etwa heißen: anmelden, ein Produkt in den Warenkorb legen und die Bestellung abschließen. Weil dabei das Zusammenspiel aller Komponenten geprüft wird, tauchen mitunter Fehler auf, die in einzelnen Komponenten- oder Integrationstests verborgen bleiben.

Hier könnte Ihr Advertorial stehen
Ein Advertorial bietet Unternehmen die Möglichkeit, ihre Botschaft direkt im redaktionellen Umfeld zu platzieren

Technisch liefert der Playwright-MCP-Server dem Agenten strukturierte Accessibility-Snapshots. Darin stehen Elemente samt Rollen und Namen – Schaltflächen, Eingabefelder oder Überschriften. Screenshots oder Vision-Modelle sind laut Dokumentation für die Interaktion nicht nötig. Dass Rollen und Namen nebenbei Hinweise auf Barrierefreiheitsprobleme geben können, ist allerdings eine redaktionelle Einschätzung.

Installation und die kleinen Haken

Für den Einstieg braucht es eine Node-Umgebung mit npm beziehungsweise npx. Die Playwright CLI lässt sich global installieren:

npm i -g @playwright/cli@latest

Anschließend wird der Playwright-MCP-Server bei Claude registriert:

claude mcp add playwright npx @playwright/mcp@latest

Das Kürzel latest macht den Einstieg bequem, kann reproduzierbare Builds aber erschweren. Für feste CI-Prozesse empfiehlt sich deshalb, Versionen zu fixieren. Klingt trocken, spart später aber womöglich eine lange Fehlersuche bei einem Test, der gestern noch lief.

Der Ablauf braucht außerdem menschliche Haltepunkte. Beim Öffnen prüft das QA-Team, ob Zielseite und Testumgebung stimmen. Beim Einlesen der Struktur geht es darum, ob alle wichtigen Elemente vorhanden und korrekt benannt sind. Vor dem Erzeugen muss klar sein, dass tatsächlich die richtige Anforderung geprüft wird. Nach der Ausführung zählen Stabilität und Wiederholbarkeit. Und wenn der Agent einen Test automatisch anpasst, darf er keinen echten Fehler einfach wegretuschieren. Ein grüner Test ist noch lange kein fachlich sinnvoller Test.

Was die KI gut kann – und wo sie hängen bleibt

Im Praxistest wurde MCP in drei Bereichen untersucht: Testfallgenerierung, Testcodegenerierung und Debugging. Aus Texteingaben kann das System strukturierte Testfälle und Testszenarien, funktionsfähigen Playwright-Code sowie Vorschläge zur Fehlerbehebung erzeugen. Dabei berücksichtigt MCP unter anderem das zu testende Feature, die Testumgebung und die erwarteten Ergebnisse.

Manuelle Testpläne mit Szenariobeschreibung, Testschritten und erwarteten Resultaten gelingen vor allem bei Cookie-Bannern, Login-Abläufen und Suchfunktionen präzise. Die Schritte sind überwiegend logisch und nachvollziehbar formuliert; gegenüber manueller Dokumentation wurde eine Zeitersparnis von bis zu 70 Prozent festgestellt. Bei individuellen Oberflächen, etwa mehrstufigen Cookie-Dialogen mit Toggles, erkennt die KI jedoch nicht alle Randfälle.

Für Buttons, Eingabefelder und einfache Klickfolgen liefert sie stabilen Playwright-Code. Mittelschwere Abläufe mit Filtern und Validierungen werden meist logisch umgesetzt, klar strukturierte Frontends lassen sich flott automatisieren. Bei iFrames erkannte die KI zunächst nicht automatisch, dass zwischen Ebenen gewechselt werden musste. Gezieltes Prompt Engineering löste das Problem. Komplexe Geschäftslogik, dynamische Filter und voneinander abhängige Eingabefelder verlangen dagegen ausführliche Anweisungen; erfahrene Testautomatisierer sind dann häufig schneller.

Ein Beispiel war die Buchung eines Fluges auf einer großen Airline-Website. Start- und Zielflughafen sowie das Datum mussten ausgewählt werden, allerdings über interaktive Buttons und Dropdowns statt über simple Eingabefelder. MCP konnte die nötigen Aktionen zunächst nicht vollständig ableiten. Erst nach mehreren Iterationen und konkreten Prompt-Anweisungen gelang die komplette Automatisierung. Die Einstiegshürde sank, ja. Schneller als eine erfahrene Testautomatisiererin war das System in diesem Fall aber nicht.

Auch beim Debugging kann der Agent helfen. Er analysiert Fehler etwa wegen veralteter Locators oder dynamischen Ladens, erkennt umbenannte oder verschobene Elemente und schlägt alternative Locators oder Interaktionsmethoden vor. Ursachen und mögliche Lösungen erklärt er in natürlicher Sprache – für weniger erfahrene Tester kann daraus ein interaktiver Lernprozess werden. Bei komplizierten Fehleranalysen bleibt Fachwissen nötig.

QA bleibt am Steuer

Der Workflow ersetzt laut iX keine QA-Ingenieurinnen und QA-Ingenieure. Ein Agent kennt weder Geschäftsrisiken noch Produktgeschichte oder frühere Fehler. Beim Anmeldeprozess muss weiterhin eine Fachkraft entscheiden, ob gesperrte Konten, abgelaufene Sitzungen und falsche Passwörter getestet werden.

Verschieben könnte sich die Arbeit trotzdem: weniger manuelles Schreiben von Selektoren und Warteschleifen, mehr Entwurf von Testfällen, Bewertung von Ergebnissen und Absicherung kritischer Pfade. Teams mit vorhandenem QA-Wissen und einer etablierten Teststrategie profitieren am ehesten. Ohne Testkultur erzeugt der Agent zwar rasch viel Testcode, aber keine automatische Teststrategie.

Der Artikel von Appmatics beschreibt die KI-Unterstützung auch für die Testplanung und das Debugging. Routineaufgaben lassen sich schneller erledigen, Testideen früher validieren, und Menschen ohne Programmiererfahrung bekommen einen leichteren Einstieg. Bei komplexen Szenarien bleibt die menschliche QA-Expertise jedoch nötig.

Die Grenzen heißen Halluzinationen, fehlender Determinismus und begrenzte Kontextlängen. Das klingt unspektakulär, kann im Testbetrieb aber ordentlich nerven. Ein Test, der bei jedem Lauf ein wenig anders entscheidet, ist eben nicht automatisch hilfreich.

Wartung, Sicherheit und der Alltag

Der größere Nutzen könnte laut redaktioneller Einschätzung sogar in der Testwartung liegen. Eine umbenannte Schaltfläche oder ein verschobenes Formular kann automatisierte Tests brechen. Liest der Agent die aktuelle Seitenstruktur, kann er Tests an die veränderten Elemente anpassen. Solche Änderungen müssen trotzdem wie normaler Code geprüft und dürfen nicht ungeprüft übernommen werden – sonst wird eine echte Regression womöglich verdeckt.

Handgeschriebene Tests kosten viel Zeit, bieten dafür vollständige menschliche Kontrolle. Recorder sind schnell, bleiben aber häufig starr und müssen bei Änderungen teilweise neu aufgenommen werden. Sprachmodelle konnten Testcode aus Beschreibungen erzeugen, schrieben ohne Zugriff auf die laufende Seite jedoch mitunter auf Verdacht. MCP schließt diese Lücke, indem der Agent die aktuelle Seite selbst lesen kann. Leistungs-, Zeit- oder Kostenzahlen für den Gesamtworkflow nennen die vorliegenden Angaben nicht.

Die Entwicklung verlief grob von fragilen Zugriffen über Positionen oder Kennungen zu besseren Warte- und Selektionsmechanismen. Recorder vereinfachten die Erstellung, erzeugten aber weiterhin oft empfindliche Tests. Nun kommt der Seitenzugriff des Agenten hinzu – mit allen Nebenwirkungen.

Ein Browser-Agent kann Seiten öffnen, Formulare ausfüllen und Aktionen auslösen. Deshalb empfiehlt der Artikel den Einsatz ausschließlich in Testumgebungen und nicht mit echten Kundendaten. Für die DACH-Region sind die Datenschutzanforderungen der DSGVO relevant. MCP-Server und Erweiterungen können mit den Rechten des Nutzers ausge