Einführung: Playwright und KI-gestütztes Test Engineering

Playwright und KI-gestütztes Test Engineering

0:00 Testautomatisierung ist gerade in Bewegung geraten. Werkzeuge, die eine Webanwendung selbst öffnen, sie erkunden und daraus Testcode vorschlagen, sind seit ein paar Monaten Alltag statt Demo. Das verändert die Arbeit — aber anders, als die Schlagzeilen vermuten lassen. Die Tests schreiben sich nicht von selbst; es entsteht eine neue Aufgabe, nämlich das Prüfen dessen, was ein Agent vorschlägt.

0:24 Genau darum geht es in diesem Seminar: Wir setzen Planner, Generator und Healer ein, und wir lernen gleichzeitig, ihren Ergebnissen begründet zu misstrauen. Vier Tage, ein durchgehendes Beispiel, viel Praxis.

Was sich durch Coding Agents ändert

0:37 Bevor wir irgendetwas installieren, klären wir die Ausgangslage. Was genau verschiebt sich, wenn ein Agent mitschreibt? Und wo bleibt die Verantwortung? Diese Frage entscheidet darüber, ob am Ende eine belastbare Suite steht oder nur eine sehr schnell entstandene. Es lohnt sich, diese Frage am Anfang sauber zu beantworten.

0:56 Wer sie überspringt, merkt erst nach ein paar Wochen, dass die Suite gewachsen ist, ohne dass die Absicherung mitgewachsen wäre. Stellen Sie sich einen sehr fleißigen Praktikanten vor, der Ihre Anwendung zum ersten Mal sieht. Er klickt sich durch, notiert alles, was er beobachtet, und schreibt daraus Testfälle. Er ist schnell, er wird nicht müde — aber er weiß nicht, was Ihr Geschäft eigentlich ausmacht. Genau so arbeitet ein Coding Agent.

1:22 Was er abliefert, ist ein Entwurf, kein geprüfter Test. Diese Unterscheidung klingt selbstverständlich, sie ist es im Alltag aber nicht: Erzeugter Code sieht fertig aus. Verantwortung für Aussagekraft und Stabilität bleibt bei Ihnen. Der Zeitgewinn ist real, und er liegt an einer bestimmten Stelle: beim Erkunden, Tippen und Selektoren-Suchen. Das war nie der interessante Teil.

1:46 Was bleibt und sogar wächst, ist die Entscheidung, was überhaupt geprüft werden soll und ob eine Behauptung stimmt. Ein Test ohne belastbare Aussage kostet Sie später Wartung, ohne je einen Fehler zu finden — das ist der teuerste Testtyp überhaupt. Man könnte sagen: Die Arbeit wandert vom Schreiben zum Lesen. Wer Reviews mag, gewinnt hier. Wer sie bisher gemieden hat, sollte jetzt anfangen.

2:10 Hinter dieser Tabelle steckt ein einziger Gedanke, und der ist zentral für alles Weitere. Ein Testlauf ist deterministisch: Gleiche Bedingungen, gleiches Ergebnis — sonst wäre er als Messinstrument wertlos. Ein Sprachmodell ist das Gegenteil: Derselbe Auftrag liefert morgen eine andere Formulierung. Beides ist in Ordnung, solange man weiß, welches Werkzeug welche Eigenschaft hat.

2:34 Praktisch heißt das: Was ein Agent erzeugt, wird geprüft. Was ausgeführt wird, wird gemessen. Deshalb steht am Ende jeder Agentenschleife in diesem Seminar ein Diff und ein Review — nie ein direkter Commit. Der Aufbau folgt bewusst nicht der Reihenfolge der Werkzeuge, sondern der Reihenfolge des Vertrauens. Erst sichern wir die Playwright-Grundlagen, denn wer Locators und Traces nicht lesen kann, kann einen Agentenvorschlag nicht beurteilen.

3:01 Dann erkunden wir die Anwendung gemeinsam mit einem Agenten. Erst danach kommen Planner, Generator und Healer — in genau dieser Reihenfolge, weil sie aufeinander aufbauen. Zum Schluss geht es um alles, was eine Suite alltagstauglich macht: Struktur, Parallelität, CI. Jeder Schritt bringt ein Artefakt hervor, mit dem der nächste arbeitet.

3:21 Diese vier Punkte begegnen einem in fast jedem Team, das gerade anfängt. Der häufigste ist der erste: Ein Agent ersetzt keine Teststrategie, er beschleunigt ihre Umsetzung. Der zweite ist der gefährlichste, weil er sich gut anfühlt — grüne Tests sind kein Qualitätsnachweis, solange niemand die Assertions gelesen hat. Der dritte passiert aus Zeitdruck: Erzeugter Code sieht plausibel aus, und Plausibilität ist bei Sprachmodellen leider die eine Eigenschaft, die garantiert vorhanden ist.

3:50 Und der vierte: Was nicht auf dem Bildschirm steht, kennt der Agent nicht. Fachwissen müssen Sie ihm geben.

Werkzeuge, Beispielanwendung und Rahmen

3:57 So viel zur Einordnung. Jetzt wird es konkret: Was muss auf Ihrem Rechner liegen, gegen welche Anwendung testen wir vier Tage lang, und welche Regeln gelten dabei für Zugangsdaten und Kosten? Wir richten die Umgebung gemeinsam ein und schauen uns die Anwendung an, mit der wir die nächsten Tage arbeiten. Danach ist der theoretische Teil erst einmal vorbei.

4:18 Unser Übungsobjekt ist ein Pflanzenversand namens Gartenklub. Er hat alles, was wir brauchen, und nichts darüber hinaus: eine Suche, Produktseiten mit Verfügbarkeiten, einen Warenkorb, eine Kasse mit Formularvalidierung und eine Redaktionsansicht für eine zweite Rolle. Klein genug, um ihn in einer Übung zu überblicken; groß genug, dass echte Fehlerfälle und Zustandsübergänge vorkommen. Wichtig ist der Rahmen: Die Anwendung läuft lokal.

4:44 Wir schicken keinen Agenten gegen ein System mit echten Kundendaten — dazu später mehr, wenn es um Sicherheit geht. Diese fünf Bausteine sind nicht zufällig gewählt. Jeder trägt eine bestimmte Art von Testproblem, die uns später begegnet. Der Katalog steht für Listen und die leere Ergebnismenge, die man beim Testen gern vergisst. Die Produktseite bringt Varianten und Verfügbarkeiten.

5:07 Der Warenkorb ist unser Zustandsautomat — dort entstehen die interessanten Fehler. Die Kasse liefert Formularvalidierung, also Meldungstexte, an denen sich Assertions bewähren müssen. Und die Rollen sorgen dafür, dass wir Berechtigungen nicht nur theoretisch behandeln. Behalten Sie diese Landkarte im Kopf, wir kommen immer wieder darauf zurück.

5:29 Die Einrichtung ist in zwanzig Minuten erledigt, wenn man sie in dieser Reihenfolge macht. Zuerst die Basis: Node in einer aktuellen LTS-Version, dann das Projekt und seine Abhängigkeiten. Danach Playwright samt Browsern — und gleich ein erster Lauf, damit Sie wissen, dass es funktioniert, bevor irgendetwas Komplizierteres dazukommt.

5:49 Der Coding Agent kommt danach, denn ohne laufende Testumgebung hat er nichts, worauf er aufsetzen könnte. Und ein Punkt, der keine Technik, sondern Disziplin ist: Zugangsdaten kommen aus einer lokalen Umgebungsdatei. Nie aus dem Repository. Vier Befehle, und die Umgebung steht. Interessant ist der zweite: Er lädt nicht nur die Browser, sondern auch die Systempakete, die sie brauchen — genau der Schritt, der später auf einem frischen CI-Runner über Erfolg und Misserfolg entscheidet.

6:19 Der letzte Befehl öffnet den HTML-Report im Browser. Machen Sie das wirklich einmal, auch wenn der Lauf trivial ist. Sie sehen dabei, wo Playwright seine Artefakte ablegt, und dieser Ort wird uns beim Debuggen noch begegnen. Ab hier ist Ihre Umgebung nachweislich lauffähig. Ein Punkt, über den selten gesprochen wird: Agentenläufe kosten. Nicht nur Geld, sondern vor allem Kontext.

6:42 Jeder Erkundungsschritt liest Seiteninhalte in das Gedächtnis des Modells, und dieses Gedächtnis ist endlich. Wird es voll, verdrängen die Seiteninhalte genau die Anweisungen, die Sie am Anfang so sorgfältig formuliert haben — der Agent wird dann nicht dümmer, er vergisst nur den Auftrag. Praktisch heißt das: kurze, gezielte Schleifen statt langer Erkundungen.

7:03 Und Reproduzierbarkeit entsteht erst durch feste Testdaten und eine feste Umgebung, nicht durch einen besseren Prompt. Jetzt sind Sie dran, und die erste Aufgabe ist bewusst unspektakulär: Bringen Sie Ihre Umgebung zum Laufen und weisen Sie das nach. Ein grüner Lauf gegen Gartenklub, ein geöffneter Report — mehr nicht. Der Grund dafür ist praktisch: Alles, was in den nächsten Tagen kommt, setzt diese Basis voraus, und ein Umgebungsproblem, das erst mitten in einer Agentenschleife auffällt, kostet doppelt so viel Zeit.

7:33 Wer früher fertig ist, startet denselben Lauf zusätzlich im UI Mode und schaut sich an, wie Playwright einen Testlauf interaktiv darstellt.