Der Prüfer – Der E2E-Test-Agent

Im vorherigen Post habe ich den Realisierungsplan- und den Developer-Agenten vorgestellt – die Macher meines Teams. Am Ende dieses Posts hatte ich angekündigt, dass das Vier-Agenten-Team durch einige spezialisierte Ergänzungen abgerundet wird. Dieser Post löst dieses Versprechen ein – mit einer Ergänzung, die für mich nicht optional ist, sondern das letzte fehlende Glied in der Kette: dem E2E-Test-Agenten.

Die vier Agenten aus den letzten Posts haben eine bewusste Lücke. Sie planen, entwerfen, zerlegen und implementieren – aber keiner von ihnen prüft am Ende automatisiert, ob das fertige Feature im echten Browser oder Simulator tatsächlich das tut, was im Use Case stand. Genau diese Lücke schließt der fünfte Agent. Ich hatte zunächst damit gearbeitet, dass der Developer-Agent am Ende eines Features auch die Unit-Tests schreibt. Aber das hat für mich nicht zum gewünschten Resultat geführt.

Das Problem nach dem Code: Grün ist nicht gleich fertig

Der Developer-Agent beendet jeden Schritt mit einem Validierungsbefehl – npm run build, ein Type-Check, vielleicht ein Linter. Ist der Befehl grün, gilt der Schritt als abgeschlossen. Das ist gut und notwendig. Aber es beweist genau eine Sache: Der Code kompiliert. Es beweist nicht, dass das Feature funktioniert.

Ein grüner Build sagt nichts darüber aus, ob die Suchleiste beim Tippen wirklich Ergebnisse anzeigt, ob das Dropdown sich beim Leeren des Feldes wieder schließt, ob bei null Treffern die richtige Meldung erscheint – oder in einer mobilen App, ob ein Tap auf den richtigen Screen navigiert und ob ein Netzwerkfehler die korrekte Fehlermeldung zeigt. Das sind Verhaltensaussagen – und Verhalten lässt sich nicht durch einen Compiler prüfen, sondern nur, indem man die Anwendung tatsächlich bedient.

In meinem alten Workflow habe ich genau das von Hand gemacht: Dev-Server starten, klicken, tippen, schauen. Für ein einzelnes Feature ist das machbar. Das Problem ist nicht der erste Durchlauf – das Problem ist der zehnte. Jedes neue Feature kann ein altes brechen, und niemand klickt nach jeder Änderung den gesamten bestehenden Funktionsumfang erneut durch. Genau hier sammeln sich die Regressionen, die man erst in Produktion bemerkt.

Die Human-in-the-Loop-Checkpoints aus den vorigen Posts fangen das nicht ab. Sie sind, wie ich in Post 12 und Post 13 beschrieben habe, bewusst auf die Richtung ausgelegt – Anforderung, Konzept, Plan. Sie stellen sicher, dass das Richtige gebaut wird. Sie stellen nicht sicher, dass das Gebaute dauerhaft funktioniert. Das ist eine andere Frage, und sie braucht ein anderes Werkzeug.

Der E2E-Test-Agent: Der Use Case wird ausführbar

Der E2E-Test-Agent läuft, nachdem der Developer-Agent den letzten Schritt des Plans abgeschlossen hat. Seine Aufgabe: einen End-to-End-Test schreiben, der das frisch implementierte Feature im echten Browser durchspielt, ihn ausführen und das Ergebnis berichten.

Das Entscheidende ist, woher er seine Testfälle nimmt. Er denkt sie sich nicht aus. Er liest das Use-Case-Dokument aus docs/usecases/, das ganz am Anfang vom Business Analysten erstellt und von mir freigegeben wurde – und übersetzt dessen Struktur direkt in Testszenarien:

• Der Hauptablauf (Happy Path) wird zum zentralen Testszenario.
• Jeder Alternativfluss wird zu einem eigenen Testfall.
• Jeder Fehlerfall wird zu einem Test, der das definierte Fehlerverhalten erzwingt und prüft.

Damit schließt sich ein Kreis, der die ganze Serie zusammenhält. Der Use Case war von Anfang an die Single Source of Truth für die Anforderung. Der Solution Architect hat daraus ein Konzept gemacht, der Realisierungsplan einen Schlachtplan, der Developer den Code. Und jetzt wird dasselbe Dokument zum Prüfmaßstab. Die Anforderung, die ich am Anfang bestätigt habe, ist exakt das, gegen das am Ende getestet wird – nicht eine Interpretation davon, die sich der Test-Agent unterwegs zurechtlegt.

In meinem Nuxt-Stack ist das Werkzeug der Wahl Playwright – der Agent startet den Dev-Server, steuert einen echten Browser, tippt in die Suchleiste, wartet auf das Dropdown und prüft die Treffer. In meinem Flutter-Projekt übernimmt das ein Flutter-Integration-Test: Der Agent startet den Simulator, navigiert durch die App, führt Gesten aus und prüft, ob die Widgets den erwarteten Zustand zeigen. Das Framework wechselt – das Prinzip nicht: Der Test bedient die Anwendung so, wie ein Nutzer es täte, und vergleicht das tatsächliche Verhalten mit dem, was der Use Case versprochen hat.

Warum nicht der Developer-Agent die Tests schreibt

Die naheliegende Frage: Wenn der Developer-Agent das Feature gebaut hat – warum schreibt er nicht gleich die Tests dazu? Er kennt den Code schließlich am besten.

Genau das ist das Problem. Er kennt den Code zu gut.

Ein Agent, der seine eigene Implementierung testet, testet tendenziell, was er gebaut hat – nicht, was gefordert war. Wenn er bei der Implementierung eine implizite Annahme getroffen hat, fließt dieselbe Annahme in den Test. Der Test wird grün, weil er die Realität des Codes abbildet, nicht die Erwartung der Anforderung. Denn die Anforderung in Form des Use Cases bekommt der Entwickler nicht, er bekommt ja 'nur' den Realisierungsplan und das Lösungskonzept. Da der Developer Agent nur auf seinem frisch implementiertem Code operiert, kann das zu einer klassischen Bestätigungsverzerrung führen, nur in Software gegossen: Der Prüfling stellt seine eigene Prüfungsfrage. Das ist mir vor allem beim Implementieren von Unit Tests aufgefallen. Ich hatte häufig viele Unit Tests und eine hohe Testabdeckung – aber trotzdem funktionierte das Feature nicht, weil die Tests nicht das prüften, was wirklich wichtig war. Was mich natürlich sehr frustrierte, weil ich dachte, ich hätte doch alles getan, um sicherzustellen, dass es funktioniert.

Der E2E-Test-Agent bekommt deshalb bewusst einen anderen/eigenen Kontext. Er sieht nicht den Plan und nicht die Implementierungsdetails. Er sieht den Use Case – die Anforderung in ihrer ursprünglichen, vom Menschen bestätigten Form – und die laufende Anwendung. Aus dieser Trennung entsteht der eigentliche Wert: Er prüft gegen die Erwartung, nicht gegen das Ergebnis. Findet er eine Abweichung, ist das ein echtes Signal – und nicht das Echo einer Annahme, die schon im Code steckte.

Es ist dasselbe Prinzip, das die ganze Serie trägt: Jeder Agent bekommt genau den Kontext, den seine Aufgabe braucht – und gerade nicht mehr. Fokus durch Beschränkung.

Human-in-the-Loop: Ich reviewe den Test, nicht nur das Ergebnis

Hier liegt der subtilste, aber wichtigste Punkt dieses Agenten. Ein grüner Testlauf ist verführerisch. Er fühlt sich nach Sicherheit an. Aber ein grüner Test, der nichts Sinnvolles prüft, ist gefährlicher als gar kein Test – weil er eine Sicherheit vorgaukelt, die nicht existiert.

In Post 12 habe ich die „Schein-Kontrolle" beschrieben: einen Human-in-the-Loop, der nominell existiert, aber faktisch nur durchwinkt. Bei Tests hat diese Falle eine eigene Ausprägung. Ein Test kann grün sein, weil das Feature funktioniert – oder weil der Test gar nichts Belastbares behauptet. Ein Klick ohne anschließende Prüfung. Eine Assertion auf ein Element, das immer da ist. Ein expect, das nie scheitern kann.

Deshalb liegt mein Checkpoint hier nicht auf dem grünen Häkchen, sondern auf dem Test-Code selbst. Ich lese, was der Agent prüft. Bildet der Test wirklich den Hauptablauf aus dem Use Case ab? Prüft er den Fehlerfall, indem er den Fehler tatsächlich erzwingt – oder tut er nur so? Sind die Assertions spezifisch genug, dass sie scheitern würden, wenn das Feature kaputtginge?

Das ist eine kompakte, gut beurteilbare Prüfung – ein paar Testfälle, in meiner Sprache, gegen ein Dokument, das ich selbst freigegeben habe. Genau die Art von Checkpoint, die ich in dieser Serie verteidige: nicht das müde Durchwinken von tausend Zeilen, sondern ein gezielter Blick auf der richtigen Abstraktionsebene, zum richtigen Zeitpunkt.

Und der Test bleibt. Anders als die manuelle Klickrunde, die mit dem Schließen des Browsers verpufft, wandert der E2E-Test ins Repository und läuft bei jeder künftigen Änderung wieder. Aus einem einmaligen „funktioniert" wird ein dauerhaftes „funktioniert immer noch". Das ist der Punkt, an dem die Investition sich verzinst: Der Test, den der Agent heute für die Suche schreibt, schützt die Suche in sechs Monaten vor einer Änderung, an die heute niemand denkt.

Ja, auch das hat seine Grenzen

Ein E2E-Test-Agent ist kein Ersatz für ein durchdachtes Testkonzept. E2E-Tests sind langsam, sie können flaky sein, und sie decken bewusst nur die Pfade ab, die im Use Case beschrieben sind – nicht jeden denkbaren Edge Case. Für feingranulare Logik bleiben Unit-Tests das bessere Werkzeug, und die gehören eher in den Verantwortungsbereich des Developer-Agenten beim Schreiben der jeweiligen Funktion.

Der E2E-Test-Agent prüft das Feature aus der Vogelperspektive des Nutzers – genau auf der Ebene, auf der der Use Case formuliert ist. Das ist seine Stärke und gleichzeitig seine Grenze. Er sagt mir verlässlich: „Der Ablauf, den du am Anfang bestellt hast, funktioniert im echten Browser." Er sagt mir nicht: „Jede einzelne Hilfsfunktion ist isoliert korrekt." Beides ist nötig. Dieser Agent liefert das Erste.

Fazit

Der E2E-Test-Agent ist der Punkt, an dem sich der Kreis schließt. Was als vager Wunsch begann und vom Business Analysten in einen Use Case gegossen wurde, kehrt am Ende als Prüfmaßstab zurück. Dieselbe Anforderung, die den ganzen Prozess gestartet hat, entscheidet darüber, ob er erfolgreich war.

Damit ist das Team komplett: Der Business Analyst und der Solution Architect stellen sicher, dass das Richtige geplant wird. Der Realisierungsplan-Agent macht den Plan umsetzbar, der Developer setzt ihn um. Und der E2E-Test-Agent beweist, dass das Ergebnis tatsächlich tut, was am Anfang gefordert war – nachvollziehbar, wiederholbar und dauerhaft im Repository verankert.

Genug Theorie. In den letzten Posts habe ich erklärt, warum jeder dieser Agenten existiert und welches Problem er löst. Im nächsten Post lasse ich den Vorhang fallen und zeige den gesamten Workflow in Action – von einem echten vagen Wunsch bis zum fertigen, getesteten Commit, mit allen Handoffs, Checkpoints und Korrekturen, die unterwegs nötig waren.