Schneller shippen — aber wer klickt noch?

Wir sind sehr gut darin geworden, Features schnell rauszubringen.

Planning-Agents lesen das Jira-Ticket. Implementierungs-Agents schreiben den Code. Test-Agents führen die Suite aus. Review-Agents prüfen den Diff. Git-Agents pushen den Branch. Die gesamte Pipeline läuft in unter 30 Minuten — und ich mache dabei eigentlich nichts außer den PR zu approven.

Aber es gab immer einen Schritt, den ich nicht automatisiert hatte: das manuelle Durchklicken der echten UI auf einem PRE-Environment, um zu prüfen, ob das Feature wirklich funktioniert.

Irgendjemand musste die stumpfe Arbeit erledigen. Einloggen. Navigieren. Klicken. Formular ausfüllen. Schalter umlegen. Liste prüfen. Löschen. Sicherstellen, dass nichts kaputt ist.

Session 13 drehte sich darum, PRs autonom zu shippen. Session 28 stellte eine andere Frage: Kann ein Agent das QA übernehmen?

Die Antwort hat mich überrascht.

Das Feature

FEAT-418 war ein substanzielles Feature: Default-Werte für Konfigurationseinträge, mit einem 3-Zustands-System („Use Default” / „Custom Value” / „No Default Available”) und Löschschutz für Einträge, die aktiv genutzt werden.

Nachdem die Implementierung auf PRE gelandet war, musste sie getestet werden. Nicht mit Unit-Tests — die hatten wir bereits. Sondern so, wie ein Mensch testet: zur Konfigurationsseite navigieren, neuen Eintrag erstellen, prüfen, ob Defaults erscheinen, „Use Default”-Schalter umlegen, Beschreibungstext prüfen, versuchen, etwas zu löschen, das gerade genutzt wird, und bestätigen, dass es blockiert wird, etwas löschen, das nicht genutzt wird, und bestätigen, dass es klappt, Browser-Konsole auf Fehler prüfen.

Die Art von Testing, die Entwickler technisch durchführen könnten — und von Herzen hassen.

Ich schrieb eine QA-Checkliste. Dann übergab ich sie an einen Agent.

307 Interaktionen

Der Agent öffnete Chrome. Navigierte zum PRE-Environment. Stieß auf die Login-Seite und hielt inne — Credentials sind Credentials, also tippte ich sie ein. Zwei-Faktor-Authentifizierung: dasselbe, ich übernahm das. Dann trat ich zurück.

Was in den nächsten 42 Minuten passierte, war eines der seltsamsten Dinge, die ich je beobachtet habe.

Der Agent arbeitete die Checkliste methodisch durch. Er las die Seitenstruktur, identifizierte die relevante Tabelle und die Buttons, klickte „Create New Entry”, füllte das Konfigurationsformular aus, speicherte — und navigierte dann zurück zur Liste, um zu prüfen, ob der neue Eintrag da war. Er fand den „Use Default”-Schalter, klickte ihn, verifizierte die geänderte Verhaltensweise. Er prüfte das Description-Feld. Er versuchte einen als in-use markierten Eintrag zu löschen und bestätigte, dass es geblockt wurde. Er fand einen nicht genutzten Eintrag und bestätigte, dass der Löschvorgang durchging.

An einem Punkt hörte er auf, UI-Elemente zu klicken, und führte JavaScript aus.

const response = await fetch('/api/config/entries');
const data = await response.json();
return data.entries.filter(e => e.hasDefaults);

Das evaluate_script-Tool ermöglicht beliebiges JavaScript im Seitenkontext. Der Agent nutzte es, um Backend-APIs direkt aufzurufen, den Session-Zustand zu prüfen und zu verifizieren, was das Backend tatsächlich gespeichert hatte — nicht nur, was die UI zeigte.

9 Punkte auf der Checkliste. 9 bestanden. Null Konsolenfehler.

307 Browser-Interaktionen insgesamt.

So funktioniert’s in der Praxis

Schritt 1: Checkliste schreiben. Das bleibt menschliche Arbeit — und das ist gut so. Du weißt, was das Feature tun soll. Schreib die Testfälle in normaler Sprache — „Eintrag mit Defaults erstellen, prüfen dass Defaults in der Liste erscheinen” reicht völlig.

Schritt 2: An den Agent übergeben. Der Agent bekommt die Checkliste und eine Chrome-MCP-Verbindung. Er fängt von vorne an und arbeitet sich Punkt für Punkt durch.

Schritt 3: Helfen wo nötig. Login-Credentials, Zwei-Faktor-Authentifizierung, alles mit echten Secrets bleibt bei dir. Der Agent hält an und fragt. Du übernimmst diese Momente, dann trittst du wieder zurück.

Schritt 4: Report prüfen. Der Agent gibt aus, was bestanden hat, was nicht, welche Auffälligkeiten er bemerkt hat. Design-Inkonsistenzen, unerwartete Fehlermeldungen, Konsolen-Warnungen — Dinge, die einem beim Durchklicken auffallen würden.

Was ich nicht erwartet hatte: Der Agent bemerkt Dinge, die nicht auf der Checkliste stehen. Während er den Löschschutz testete, fiel ihm ein Edge Case im Pagination-Verhalten auf, der in keinem Testfall stand. Er hat ihn trotzdem gemeldet.

Warum das wichtiger ist als es klingt

Schnelle Pipelines erzeugen Druck.

Wenn man von Ticket zu PR in 30 Minuten kommt, ist der Engpass nicht mehr die Entwicklung. Sondern alles danach. Code-Review. QA-Freigabe. Deployment-Genehmigungen. Die menschlichen Prozesse, die nicht auf dieselbe Art skalieren wie der Coding-Prozess.

Wenn man 5x schneller shippt, aber QA noch manuell ist, hat man keine 5x schnellere Pipeline — man hat 5x mehr QA-Backlog. Features stapeln sich. Das PRE-Environment füllt sich mit ungeprüften Änderungen. Die Menschen, die klicken müssen, werden überwältigt und fangen an, Abkürzungen zu nehmen.

Agentische Entwicklung ohne agentisches QA ist unvollständig. Man hat den Engpass an einer Stelle beseitigt und an einer anderen neu geschaffen.

Die Frage ist nicht mehr „können wir schneller shippen?” — das ist beantwortet. Die Frage ist: „Sind wir bereit, dieselbe Geschwindigkeit über den gesamten Lifecycle hinweg durchzuziehen?”

Die parallele Zukunft

Jetzt wird es interessant.

Browser-QA mit einem einzelnen Agent ist nützlich. Er nimmt dem Menschen die Klick-Arbeit ab. Aber ein Agent ist noch sequenziell — er arbeitet die Checkliste genauso durch wie ein einzelner Mensch.

Zehn Agents mit zehn Browser-Sessions ist etwas anderes.

Zehn Agents, die gleichzeitig auf das PRE-Environment zugreifen, sind nicht einfach 10x schnelleres QA — das ist ein Lasttest. Race-Condition-Erkennung. Der Unterschied zwischen „funktioniert das, wenn eine Person es benutzt” und „funktioniert das, wenn echter Traffic draufkommt.”

Feature Flags mit gestaffeltem Rollout? 5 Agents mit aktiviertem Flag, 5 ohne — gleichzeitig, beide gegen dasselbe Backend. Erstellungs- und Löschoperationen parallel auf denselben Ressourcen. Session-Handling unter gleichzeitiger Last. Die Art von Bugs, die nur auftauchen, wenn mehrere Nutzer gleichzeitig aktiv sind — jetzt systematisch getestet, bevor das Feature live geht.

Das Einzelagenten-Modell aus Session 28 funktioniert schon heute. Der Multi-Agent-Schwarm ist das nächste Ziel.

Was nicht reibungslos lief

Damit das vollständig ist:

MCP-Berechtigungen sind standardmäßig gesperrt. Als der Agent das erste Mal ein Formular ausfüllen wollte, klappte es nicht — fill, type_text und press_key waren nicht auf der erlaubten Tool-Liste. Ich musste manuell 13 Chrome DevTools MCP-Tools zur Einstellungsdatei hinzufügen, bevor Formular-Interaktionen funktionierten. Einmaliger Setup-Aufwand, aber eine echte Überraschung wenn man damit nicht rechnet.

Vollständige DOM-Reads auf großen Tabellen sind teuer. Die Datentabelle hatte 1496 Zeilen. Das vollständige DOM-Abbild des Agents von dieser Seite war riesig — Tausende von Tokens, die den Kontext schnell auffressen. Wir haben das mit evaluate_script umgangen, um Daten direkt abzufragen statt das DOM zu parsen. Wer einen QA-Workflow aufsetzt, sollte das von Anfang an einplanen: vollständige Seiten-DOM-Reads vermeiden, JavaScript-Queries für Datenverifikation nutzen.

Ein Browser, ein Agent. Das Chrome DevTools MCP ist single-threaded pro Browser-Instanz. Für das parallele Schwarm-Modell braucht man separate Browser-Kontexte — kein technisches Hindernis, nur eine Architektur-Überlegung beim Skalieren.

Die stumpfe Arbeit — neu verteilt

Das Bild, zu dem ich immer wieder zurückkomme: QA ist wichtige Arbeit, und sie ist oft auch langweilige Arbeit. Dieselben Pfade nach jedem Deployment durchklicken. Dieselben Dinge verifizieren. Regressionen abfangen, bevor sie Nutzer erreichen.

Diese Langweiligkeit ist kein Zeichen dafür, dass die Arbeit unwichtig ist. Es ist ein Zeichen dafür, dass sie sich gut für Automatisierung eignet.

Das Ziel ist nicht, QA abzuschaffen. Es ist, den Menschen die Teile zurückzugeben, die echtes Urteilsvermögen brauchen. Exploratives Testen. Edge-Case-Design. Die seltsamen Szenarien, auf die nur ein erfahrener Mensch käme. Lass den Agent die Checkliste abarbeiten. Lass den Menschen das Denken übernehmen.

Das Kollaborationsmodell: Du schreibst die Checkliste, du übernimmst die Secrets, du schaust dir den Report an. Der Agent macht alles dazwischen. Es ist weniger „Agent ersetzt QA” und mehr „Agent übernimmt den langweiligen Teil, damit QA sich auf den interessanten konzentrieren kann.”

Noch eine Sache

Session 13 hat gezeigt: Wie sieht es aus, wenn die Pipeline zum Kollegen wird?

Session 28 hat etwas anderes gezeigt: Wie sieht es aus, wenn der Kollege den Klick-Job übernimmt?

Sehr ähnlich wie erwartet. Methodisch. Gründlich. Gelegentlich überraschend auf die beste Art.

307 Interaktionen. 42 Minuten. 9/9 bestanden. Kein einziges Mal gemurrt, weil er schon wieder durch dieselbe UI klicken musste.

Wer eine schnelle Pipeline betreibt und QA noch der manuelle Schritt ist — das ist der nächste, den es zu automatisieren gilt.