Agentisches Testing – die Rolle von Agenten im E2E-Test-Stack

• Das Engineering-Team von Slack führte mehr als 200 agentische Workflows aus, um zu prüfen, ob agentenbasiertes E2E-(End-to-End-)Testing herkömmliche deterministische Tests ersetzen kann
• Während traditionelle E2E-Tests einen festen UI-Pfad erzwingen, prüfen Agenten, ob ein Ziel (Goal) erreicht wird, und gelangen über unterschiedliche Wege zum gleichen Ergebnis
• Agentische Ausführungen kosten 15–30 US-Dollar pro Lauf und dauern über 10 Minuten, haben aber in Bezug auf Zuverlässigkeit klar erkennbare Einsatzgebiete
• Der Playwright-MCP-Ansatz verzeichnete niedrigere Fehlerraten und einen geringeren Token-Verbrauch als CLI- oder Code-Generierungsansätze; die Stabilität der Ausführungsumgebung entscheidet über das Ergebnis
• Agentisches Testing ersetzt bestehende Tests nicht, sondern wird an der Spitze der Testpyramide als zusätzliche Schicht für Exploration, Debugging und die Verifikation komplexer Abläufe ergänzt

---

Von Journeys zu Goals (From Journeys to Goals)

• Traditionelle E2E-Tests validieren eine bestimmte Journey, die der UI folgt → Klick → Klick → Eingabe → Assertion
• Agentenbasierte Tests prüfen, ob sich ein Ziel erreichen lässt, ausgedrückt durch Anweisungen wie „eine Thread-Nachricht senden“ → Ziel → Agent passt sich an → Ergebnis validieren
  • Der Kernunterschied: „Tests erzwingen die Journey, Agenten validieren das Ziel“
• Der gesamte Workflow (Login → Suche → Ergebnis → Zurücksetzen) blieb konstant, aber die tatsächliche Reihenfolge der Aktionen unterschied sich bei jedem Lauf
  • unterschiedliche Eingabemethoden (auf Suchvorschlag klicken vs. Enter drücken)
  • unterschiedliche Navigationsmuster (Suche erneut ausführen vs. bestehenden Zustand wiederverwenden)
  • hinzugefügte oder ausgelassene Schritte (zusätzliche Klicks, Snapshots, Zwischenschritte)
• Diese Flexibilität bringt Trade-offs bei Zuverlässigkeit, Kosten und Laufzeit mit sich

• Fragestellung

  • Die zentrale Frage war, ob ein Ansatz, der 15–30 US-Dollar pro Lauf kostet und über 10 Minuten dauert, in moderne Test-Workflows passt
  • Nach über 200 Ausführungen zeigte sich, dass der Ansatz sich grundlegend von traditionellen Tests unterscheidet und zugleich eine hohe Zuverlässigkeit sowie klare Einsatzgebiete besitzt
  • Fortschritte bei Large Language Models (LLMs), die Code schreiben, Fehler debuggen und UIs direkt bedienen können, ermöglichen dieses neue Ausführungsmodell

Versuchsaufbau (Our Experiment)

• Um Zuverlässigkeit, Ausführungsgeschwindigkeit und Kosten zu messen, wurden in mehreren Konfigurationen mehr als 200 automatisierte Läufe durchgeführt

• Ausführungsmodelle (drei Ansätze)

  • Agent + Playwright MCP: Der Agent interagiert mit dem Browser über vordefinierte Browseraktionen (Elemente anklicken, Eingaben machen, DOM-Zustand lesen usw.) und behält persistenten Kontext (DOM-Snapshots, Logs)
  • Agent + Playwright CLI: Führt Playwright-CLI-Befehle in der Shell aus und arbeitet Schritt für Schritt, wobei nach jedem Schritt der aktualisierte UI-Zustand ausgewertet wird, um die nächste Aktion zu bestimmen
  • Generated Playwright Tests: Ein AI-Agent erzeugt aus einer natürlichsprachlichen Beschreibung deterministischen Playwright-Code, führt ihn als Standard-E2E-Test aus und verbessert ihn iterativ, bis er besteht

• Testumgebung

  • MCP- und CLI-Agentenmodell: Claude Sonnet 4.5
  • Modell für generierte Playwright-Tests: Claude Opus 4.6
  • Ausführung: nicht-interaktives Claude Code (claude -p)
  • Browser-Tools: Playwright MCP, Playwright CLI
  • Umgebung: Slack Dev API MCP; alle Experimente wurden in Test-Workspaces mit Nicht-Produktionsdaten durchgeführt

• Test-Flows (zwei Komplexitätsstufen)

  • Thread Reply (einfach): Workflow mit etwa 15–20 Schritten, darunter Kanal erstellen, Nachricht senden, Thread-Antwort verfassen und Thread-Zustand verifizieren
  • Search Discovery (mittlere Komplexität): Workflow mit etwa 25–30 Schritten, darunter Suchbegriff eingeben, Ergebnisse erkunden, zwischen Ansichten wechseln (Suche, Kanal, Thread) und erwartete Resultate verifizieren

• Eingabeformate

  • Natürliche Sprache (NL): Menschenlesbare Anweisungen, die Workflow und erwartete Ergebnisse als Schritt-für-Schritt-Liste beschreiben
  • Strukturiertes YAML: Dasselbe Workflow in strukturierter Form mit Schritten, Aktionen, Zielobjekten und erwarteten Ergebnissen
    • Der Unterschied liegt nicht im Detailgrad, sondern in der Darstellungsform — natürliche Sprache muss der Agent interpretieren und abbilden, YAML definiert diese Zuordnung expliziter

• Experimentmatrix

  • Jede Konfiguration wurde 20-mal ausgeführt; insgesamt wurden 5 Experimente (MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, Generated Tests-NL) auf die beiden Flows Thread Reply und Search Discovery angewendet

Beobachtungen (What We Observed)

• Zusammenfassung der Ergebnisse

  • Agent (Playwright MCP): Fehlerrate 0 % (Thread Reply) / ca. 12 % (Search Discovery), durchschnittlich 5–8 Minuten
  • Agent (Playwright CLI): Fehlerrate ca. 12 % / ca. 20 %, durchschnittlich 9–11 Minuten
  • Generated Playwright Tests: Fehlerrate ca. 8 % / ca. 48 %, durchschnittlich 3 Minuten

• Zuverlässigkeit (Reliability)

  • Je komplexer der Flow wurde, desto deutlicher zeigte sich der Unterschied bei der Zuverlässigkeit
  • Playwright MCP war am stabilsten — in einfachen Szenarien nahezu 0 % Fehlerrate, selbst bei komplexeren Flows zwischen 0 und 12 %
  • Playwright CLI zeigte höhere Fehlerraten (ca. 12–20 %), meist verursacht durch Ausführungsprobleme wie Authentifizierung, Navigations-Timing oder instabile Sessions und nicht durch das Schlussfolgern des Modells
  • Generierte Tests waren bei einfachen Flows solide (ca. 8 %), verschlechterten sich aber bei komplexen Workflows deutlich (ca. 48 %)
    • Sie lagen nicht komplett daneben, sondern kamen meist 70–80 % des Flows weit, bevor sie bei der letzten Interaktion oder Assertion scheiterten
    • Ursache waren Schwankungen im UI-Zustand und nicht passende Abstraktionen — die Tests wurden aus lose spezifizierten natürlichsprachlichen Flows erzeugt und nutzten bestehende Page-Object-Abstraktionen wieder, was präzises Targeting von Elementen erschwerte
  • Mit wachsender Komplexität wurde die Zuverlässigkeitslücke größer; agentennative Ausführungsmodelle wie MCP erwiesen sich als stabiler
    • MCP hält eine Echtzeit- und stabile Sicht auf die App aufrecht, während CLI den Zustand nach jedem Schritt aus Snapshots rekonstruieren muss — je länger der Flow, desto stärker summieren sich Abweichungen
    • MCP scheint erfolgreiche Interaktionen früherer Schritte innerhalb derselben Session wiederzuverwenden, während CLI eher wirkt, als würde es bei jedem Schritt neu beginnen (nicht explizit gemessen)

• Geschwindigkeit (Speed)

  • Generierte Tests waren durchgängig am schnellsten (ca. 3 Minuten), MCP lag bei ca. 5–8 Minuten, CLI bei ca. 9–11 Minuten
  • Die Werte für generierte Tests umfassen Testgenerierung plus Ausführung; jeder Test wurde einmal generiert und anschließend fünfmal ausgeführt, der angegebene Wert ist der Durchschnitt
    • Die reine Ausführung ist deutlich schneller — Thread Reply ca. 32 Sekunden, Search Discovery ca. 45 Sekunden
    • In CI-Umgebungen mit wiederholten Läufen wird der einmalige Generierungsaufwand vernachlässigbar, wodurch deterministische Tests effizient skalieren
  • Agentische Workflows verursachen bei jedem Lauf erneut Kosten — jeder Schritt umfasst Beobachtung des UI-Zustands, Ableitung der nächsten Aktion, Ausführung der Aktion und Verifikation des Ergebnisses

• Anpassungsfähigkeit (Adaptability)

  • Nur etwa 20 % der Ausführungen folgten derselben Aktionsreihenfolge; die meisten fanden unterschiedliche gültige UI-Pfade zum gleichen Ziel
    • Menüs in anderer Reihenfolge öffnen
    • leicht unterschiedliche UI-Elemente auswählen
    • alternative Navigationspfade verwenden
  • Zur Messung wurden Action Signatures zwischen den Läufen verglichen — geordnete Listen der Tool-Aufrufe und UI-Aktionen, die der Agent ausführte
    • Vor dem Vergleich wurden Parameter, Warte-/Snapshot-Aktionen und äquivalente Tool-Varianten (fill vs. type) normalisiert, sodass nur sinnvolle Unterschiede gezählt wurden
  • Selbst wenn das Endergebnis korrekt war, unterschied sich die Reihenfolge der Aktionen meist — traditionelle E2E-Tests erzwingen eine einzige deterministische Journey, Agenten erkunden die Oberfläche und prüfen, ob der Zielzustand erreichbar ist

• Kosten und woher sie kommen (Cost and Where It Comes From)

  • Agentische Ausführungen kosten typischerweise 15–30 US-Dollar pro Lauf und sind damit deutlich teurer als traditionelle Tests
  • Analyse des Token-Verbrauchs für denselben Search-Discovery-Flow
    • MCP (Opus 4.6) ca. 3,8 Mio., MCP (Sonnet 4.5) ca. 3,5 Mio., MCP (Haiku 4.5) ca. 5,7 Mio.
    • CLI (Opus 4.6) ca. 6 Mio., Code Gen (Opus 4.6) ca. 7 Mio.
  • Wichtiger als das Modell ist die Art der Ausführung — Haiku verbrauchte mehr Tokens, dennoch lagen alle MCP-Ansätze unter CLI und Code Gen
  • Analyse der Session-Ausführung in Claude Code: Die zugrunde liegende API ist stateless, daher werden bei jedem Turn der vollständige System-Prompt und die gesamte Gesprächshistorie erneut gesendet
    • Die Kosten werden nicht vom Modell-Output bestimmt, sondern von der Geschwindigkeit der Kontextakkumulation und der Zahl der Turns
  • Zahl der Turns: MCP (Opus/Sonnet) ca. 40, MCP (Haiku) ca. 60, CLI (Opus) ca. 85, Code Gen (Opus) ca. 70
    • Bei CLI wird jede Browserinteraktion in mehrere Befehle aufgeteilt, etwa Aktion, Warten, Snapshot, Lesen, Elementabfrage — im Mittel 85 Turns
    • MCP kombiniert Interaktion und Zustandsrückgabe in einem einzigen Roundtrip
    • Jeder zusätzliche Turn verursacht erneut die Kosten des vollständigen System-Prompts und der bisherigen Gesprächshistorie
  • Was den Kontext auffüllt
    • MCP und CLI: Browser-Snapshots sind die Hauptnutzlast — Accessibility-Tree-Snapshots, die Playwright MCP zurückgibt, sammeln sich über alle nachfolgenden Turns an
    • Code Gen: Bei jedem Retry sammeln sich vollständige Error Traces, Assertion-Fehler und DOM-Zustände aus der Test-Runner-Ausgabe an
  • Der Großteil der Kosten entfällt auf die erneute Übertragung bereits gesehener Inhalte; neue Informationen pro Turn machen nur einen kleinen Teil aus
  • Der Token-Verbrauch wurde in diesem Stadium nicht optimiert — als Einsparungsmöglichkeiten werden Prompt-Caching, Kontextkompaktierung und geringere Snapshot-Frequenz genannt
  • Aufgrund der Kosten eignet sich der Ansatz derzeit eher für gezieltes Debugging und exploratives Testing als für häufige CI-Läufe; künftige Modelle und Tools könnten das verbessern

• Die Bedeutung der Infrastruktur (MCP vs CLI)

  • Nicht nur das Modell, auch die Ausführungsumgebung beeinflusst die Zuverlässigkeit stark — MCP 0–12 %, CLI 12–20 % Fehlerrate
  • Die meisten CLI-Fehler entstanden durch Authentifizierungs- und Navigationsprobleme (Login-Fehler, Timeouts, instabile Sessions), also durch die Ausführungsebene und nicht durch Agenten-Reasoning
  • Playwright MCP bietet strukturierte Browser-Primitiven und eine enge Integration mit agentischen Tool-Call-Workflows, während CLI eine zusätzliche Schicht zwischen Agent und Browser einführt
  • Unterschied bei der Parallelisierung: MCP lässt sich leicht parallel ausführen, CLI ist schwerer zu parallelisieren und läuft meist sequenziell
  • Zuverlässigkeit, Geschwindigkeit und Kosten hängen nicht nur vom Modell ab, sondern auch von der Stabilität und dem Design der Ausführungsumgebung

• Grenzen der Ausführungskapazität (Execution Capability Boundaries)

  • Das Experiment konzentrierte sich auf UI-Workflows innerhalb einer einzelnen Session
  • Flows über mehrere Workspaces hinweg oder Workflows mit mehreren Browserfenstern bringen andere Herausforderungen mit sich, bei denen die Wahl des Ausführungsmodells genauso wichtig werden kann wie der Agent selbst
    • Bei MCP kann in langen Flows die Beobachtungsschleife wachsen und dadurch Kostenprobleme verursachen
    • Bei CLI können die Koordinationskomplexität und der Token-Verbrauch bei der Verwaltung mehrerer Browser-Sessions steigen
  • Beide Ansätze können solche Szenarien unterstützen, aber mit unterschiedlichen Trade-offs — im Experiment wurde das nicht untersucht, für Evaluierungsteams ist es jedoch ein wichtiger Punkt

Die Rolle agentischen Testings in der Testpyramide

• Agentisches Testing ersetzt bestehende Ansätze nicht, sondern ergänzt sie um neue Fähigkeiten

• Deterministische E2E-Tests

  • Am besten geeignet für schnelle, wiederholbare Regressionstests in CI
    • von Menschen geschrieben oder von AI generiert
    • schnell und wiederholbar, CI-freundlich
    • geringe Betriebskosten
    • erzwingen eine bestimmte UI-Journey

• Agentisches Testing

  • Startet nicht mit einem festgelegten Skript, sondern vom Ziel aus — beobachtet die UI, leitet den aktuellen Zustand ab und entscheidet, wie das gewünschte Ergebnis erreicht werden kann
    • Erkundung komplexer UI-Verhalten
    • Debugging instabiler (flaky) Workflows
    • Reproduktion von Produktions-Bugs

• Die Testpyramide mit agentischer Schicht

  • Aus Systemsicht validiert agentisches Testing echte Nutzer-Workflows über die UI auf derselben Ebene wie E2E-Tests; der Unterschied liegt in der Art der Ausführung des Workflows
  • Die effektivste Teststrategie der Zukunft wird beide Ansätze kombinieren — deterministische Tests bilden das stabile Fundament für CI, während agentisches Testing an der Spitze der Pyramide Exploration, Debugging und die Verifikation komplexer Abläufe übernimmt