Slack und agentisches End-to-End-Testing: Wie UI-Tests resilienter werden
Slack hat agentisches Testing nicht als Ersatz für CI-Tests gebaut, sondern als zusätzliche Explorationsschicht. Der Praxischeck zeigt, wo adaptive Browser-Agenten helfen, wo sie teuer werden und welche Leitplanken unverzichtbar sind.
Ein End-to-End-Test kann grün sein und trotzdem am falschen Problem vorbeilaufen. Oder er kann rot werden, weil ein Button verschoben wurde, obwohl der eigentliche Produktfluss noch funktioniert. Slack beschreibt mit „agentic testing“ einen Versuch, diese Lücke nicht mit noch mehr fragilen Selektoren zu füllen, sondern einen Agenten ein Ziel prüfen zu lassen: Kann eine Person in diesem Test-Workspace eine Nachricht in einem Thread senden und ist sie anschließend dort sichtbar?
Das ist keine neue Produktkategorie und kein Freifahrtschein für KI im Testsystem. Slack hat mehr als 200 agentische E2E-Läufe mit Playwright MCP, Playwright CLI und von einem Agenten erzeugten Playwright-Tests verglichen. Die Experimente liefen mit nicht-produktiven Daten. Die interessante Frage lautet deshalb nicht „Ersetzt der Agent unsere Tests?“, sondern: An welcher Stelle in der Testpyramide bringt sein flexibler Weg einen echten Vorteil?
Von der Reise zum Ziel
Ein klassischer Test beschreibt eine Reise: klicken, klicken, eingeben, prüfen. Diese Form ist wertvoll, weil sie schnell, reproduzierbar und als Regression in CI gut kalkulierbar ist. Ihr Nachteil ist die enge Bindung an den Weg. Ändert sich die Oberfläche, kann ein Selektor brechen, obwohl das fachliche Ziel noch erreichbar wäre.
Ein agentischer Test beschreibt dagegen ein Ziel und die erwartete Beobachtung. Der Agent sieht den aktuellen Zustand, wählt eine Aktion und prüft anschließend, ob der nächste Zustand plausibel ist. Bei Slack blieb der grobe Ablauf gleich, aber die konkrete Folge der Aktionen wechselte: Eine Suche wurde einmal über einen Vorschlag und ein anderes Mal mit Enter bestätigt; ein bereits geöffneter Zustand wurde wiederverwendet oder neu aufgebaut.
Diese Freiheit ist nützlich, aber sie ist nicht kostenlos. Ein Agent kann einen anderen gültigen Weg nehmen, einen unnötigen Umweg gehen oder ein scheinbar plausibles Ergebnis falsch bewerten. Deshalb muss die Aussage am Ende weiterhin von expliziten Assertions und einem kontrollierten Test-Workspace kommen. „Der Agent hat einen Weg gefunden“ ist noch kein belastbarer Qualitätsnachweis.
Was Slack tatsächlich gemessen hat
Slack verglich drei Ausführungsmodelle: einen Agenten mit Playwright MCP, einen Agenten mit Playwright CLI und generierte Playwright-Tests, die anschließend deterministisch liefen. Untersucht wurden unter anderem ein einfacher Thread-Reply und eine komplexere Such- und Navigationsaufgabe. Die Eingaben gab es sowohl als natürliche Anweisung als auch als strukturierte YAML-Beschreibung.
Im einfachen Thread-Flow lag der MCP-Agent in diesem Versuch bei einer Ausfallrate von null Prozent, im komplexeren Search-Discovery-Flow bei ungefähr zwölf Prozent. Der CLI-Ansatz lag bei etwa zwölf beziehungsweise zwanzig Prozent. Die generierten Playwright-Tests waren im einfachen Ablauf solide, fielen im komplexeren Flow aber deutlich häufiger aus. Das sind Ergebnisse dieses Versuchsaufbaus, keine allgemeine Rangliste für jedes Team und jede Anwendung.
Auch die Laufzeit ist ein Teil der Wahrheit. Die MCP-Läufe dauerten im Mittel etwa fünf bis acht Minuten, CLI-Läufe ungefähr neun bis elf Minuten. Generierte Tests lagen inklusive Generierung bei etwa drei Minuten und waren bei wiederholter Ausführung noch günstiger. Slack nennt für agentische Läufe in diesem Experiment grob 15 bis 30 Dollar pro Ausführung. Für jeden Commit wäre das schwer zu rechtfertigen; für die gezielte Untersuchung eines flakey Flows kann es trotzdem sinnvoll sein.
Warum die Ausführungsschicht so viel ausmacht
Der Unterschied zwischen MCP und CLI ist nicht bloß eine Geschmacksfrage. MCP liefert dem Agenten Browseraktionen und den beobachteten Zustand in einer engeren Schleife. Beim CLI-Modell werden Aktionen, Wartezeiten, Snapshots und weitere Kommandos leichter zu separaten Gesprächsrunden. Slack beobachtete dadurch mehr Kontextwachstum und mehr Gelegenheiten für Authentifizierungs-, Timing- oder Navigationsfehler.
Das spricht nicht automatisch für MCP in jedem Projekt. Ein langer Flow kann auch mit MCP teuer werden, weil jeder neue Snapshot in den Kontext gelangt. Umgekehrt kann CLI mit einer guten Session-Verwaltung und sparsamen Beobachtungen ausreichend sein. Der praktische Test ist daher: Wie viele Informationen werden pro Schritt wirklich neu gebraucht, wie wird der Zustand gespeichert und lässt sich ein Fehlschlag mit denselben Eingaben nachvollziehen?
Für den Einstieg ist eine klare Aufgabenteilung robuster. Playwright oder Cypress bleiben die Werkzeuge für kurze, wiederholbare Checks. Ein Agent übernimmt zunächst die Fälle, in denen die Oberfläche häufig driftet, ein Fehler schwer zu reproduzieren ist oder eine feste Klickfolge zu viel Pflege erzeugt. Die erfolgreiche agentische Ausführung kann anschließend als deterministischer Test konserviert werden. So entsteht aus Exploration wieder eine günstige Regression, statt ein teurer Dauerlauf zu werden.
Guardrails sind Teil des Tests
Ein Agent darf nicht „einfach ausprobieren“, bis etwas grün aussieht. Vor jedem Lauf gehören vier Dinge fest in den Auftrag:
- Testsystem: eine isolierte Umgebung mit künstlichen Konten und Daten, niemals ein unbeschränktes Produktionskonto.
- Ziel und Assertion: ein beobachtbarer Endzustand, etwa eine konkrete Nachricht im richtigen Thread, nicht nur „finde heraus, ob es funktioniert“.
- Aktionsraum: erlaubte Seiten, Tools, Schreiboperationen und maximale Schritte; riskante Aktionen brauchen eine Sperre oder menschliche Freigabe.
- Abbruch und Trace: Zeit- und Schrittlimit, Screenshot oder DOM-Zustand an wichtigen Punkten, Tool-Aufrufe, Ergebnis und Grund des Abbruchs.
Diese Regeln sind keine Bürokratie neben dem eigentlichen Test. Sie bestimmen, ob ein Team einen roten Lauf untersuchen kann. Ein guter Trace beantwortet: Welchen Zustand hat der Agent gesehen, warum hat er diese Aktion gewählt, welche Alternative wurde verworfen und welche Assertion ist fehlgeschlagen? Ohne diese Kette bleibt die vermeintliche Resilienz eine schwer reproduzierbare Momentaufnahme.
So würde ich den Piloten starten
Für ein Team mit einem flakey UI-Flow reicht ein kleiner Pilot. Zuerst werden zehn bis zwanzig reale, aber nicht sensible Fehlersituationen gesammelt. Danach wird für einen einzigen Ablauf ein Ziel mit klarer Assertion formuliert. Der Lauf startet außerhalb der normalen CI, mit einem festen Budget und einer Aufzeichnung aller Entscheidungen.
Anschließend werden drei Kennzahlen getrennt betrachtet: Erreicht der Agent das Ziel, wie oft benötigt er menschliche Korrektur und wie hoch sind Laufzeit und Kosten? Zusätzlich muss geprüft werden, ob die Flexibilität echte UI-Änderungen abfedert oder nur zufällige Wege produziert. Erst wenn diese Antworten belastbar sind, lohnt die nächste Stufe: agentische Exploration bei Pull Requests oder automatische Erstellung eines stabilen Playwright-Tests aus einem erfolgreichen Lauf.
Fazit: Ergänzen statt ersetzen
Slack liefert einen nüchternen Beitrag zur Agenten-Debatte. Agentische E2E-Tests können UI-Flows flexibler erkunden und bei schwierigen Fehlern schneller Hinweise liefern. Sie sind aber langsamer, teurer und weniger selbstverständlich reproduzierbar als deterministische Tests. Der vernünftige Platz ist deshalb zunächst eine zusätzliche Schicht für Exploration, Debugging und Produktionsfehler-Reproduktion in einer sicheren Umgebung.
Die beste Architektur ist kein Entweder-oder. Skripte prüfen den bekannten Weg in CI. Agenten untersuchen, ob das Ziel auch dann erreichbar bleibt, wenn sich der Weg verändert. Und sobald ein flexibler Lauf einen stabilen, häufig benötigten Ablauf gefunden hat, wird daraus wieder ein kleiner, transparenter Test. Genau diese Rückkopplung macht aus einem interessanten Experiment eine brauchbare Engineering-Praxis.
Häufige Fragen
FAQ: Agentisches E2E-Testing
Ersetzt ein Agent klassische UI-Tests?
Nein. Deterministische Tests bleiben für schnelle Regressionen, Verträge und CI unverzichtbar. Agentische Läufe ergänzen sie dort, wo UI-Flows variieren oder schwer zu untersuchen sind.
Warum nicht jeden Test agentisch ausführen?
Die Slack-Experimente zeigen höhere Laufzeit und deutlich höhere Kosten pro Lauf. Für jeden Commit wäre das meist unnötig; gezieltes Debugging und Exploration passen besser.
Was ist die wichtigste Sicherheitsmaßnahme?
Ein isoliertes Testsystem mit künstlichen Daten und begrenzten Aktionen. Zusätzlich braucht jeder Lauf ein klares Ziel, eine Assertion und ein Abbruchlimit.
MCP oder CLI?
Das hängt von der Ausführungsschicht ab. MCP war im Slack-Versuch stabiler und kompakter, aber kein universelles Versprechen. Entscheidend sind Zustand, Beobachtungsfrequenz und reproduzierbare Traces.