Testautomatisierung beschleunigen

Testautomatisierung beschleunigen

0:00 Testautomatisierung war lange die Eintrittshürde der QA: Man braucht echte Programmierkenntnisse, kennt die Struktur des Projekts, richtet ein Framework ein — und investiert Wochen, bevor der erste Nutzen ankommt. Genau diese Hürde senkt generative KI spürbar. In diesem Modul arbeiten wir uns durch alle drei Ebenen: Unit-Tests für einzelne Funktionen, Integrationstests über mehrere Schichten und End-to-End-Tests im Browser.

0:25 Und wir werden sehen: Das Interessanteste ist nicht, dass die KI Tests schreibt. Interessanter ist, dass sie unterwegs die fehlende Infrastruktur gleich mit aufbaut.

Unit-Tests mit KI erzeugen

0:35 Starten wir auf der untersten Ebene — bei einzelnen Funktionen. Hier ist der Nutzen am schnellsten sichtbar: eine überschaubare Aufgabe, ein sofort überprüfbares Ergebnis. Und hier lernen wir zwei Arbeitsweisen kennen, die für alle folgenden Kapitel gelten und die den Unterschied zwischen brauchbaren und beliebigen Ergebnissen ausmachen — der Plan vor der Umsetzung und die bewusst klein gehaltene Aufgabe.

0:58 Ein echter Unit-Test prüft eine Funktion für sich allein — ohne Datenbank, ohne Netzwerk, ohne gerendertes Interface. Das klingt nach einer Formalie, ist aber der Kern: Wenn ein solcher Test rot wird, wissen Sie sofort, wo das Problem liegt. Bei uns sind das die Nährwertberechnung und die Prüfung auf ausgewogene Makro-Verteilung.

1:17 Zwei überschaubare Funktionen mit klaren Eingaben und Ausgaben, jeweils mit Erfolgsfall, Fehlerfall und Grenzfällen. Genau solche Funktionen sind für die KI dankbare Kandidaten — die Aufgabe ist eng umrissen, und das Ergebnis lässt sich sofort überprüfen. Worauf es bei diesem Prompt ankommt, ist der Scope — und zwar so konkret, dass kein Spielraum bleibt: diese Datei, diese zwei Funktionen.

1:41 Wer stattdessen „schreib Unit-Tests für das Nährwert-Feature" sagt, bekommt einen breiten, mittelmäßigen Wurf. Der zweite wichtige Block sind die Regeln: keine Datenbank, kein Netzwerk, kein Rendering. Ohne diese Ansage entstehen gern Tests, die irgendwo doch Infrastruktur anfassen — und dann haben Sie keinen Unit-Test mehr, sondern einen langsamen Integrationstest mit falschem Etikett.

2:04 Und ganz am Schluss: Tests ausführen und Coverage melden lassen. Das schließt die Schleife. Diese Punkte klingen banal und machen in der Praxis den größten Unterschied. Der Plan-Modus ist der wichtigste davon: Man lässt das Werkzeug erst beschreiben, was es tun will, prüft das — und gibt dann frei. Das ist die günstigste Stelle für eine Kurskorrektur, denn danach kostet jede Änderung schon Code.

2:28 Der zweite Hebel ist die Größe der Aufgabe: klein und eng schlägt groß und offen, jedes Mal. Und wenn im Projekt schon Tests existieren, findet das Werkzeug sie und übernimmt deren Struktur. Beispiele wirken hier stärker als jede Beschreibung guten Stils. Der rote Faden dieser Schritte ist eine bewusst eingebaute Bremse.

2:47 Zwischen Auftrag und Code liegt ein Plan, und der lässt sich mit einem Satz nachschärfen — etwa der Bitte, bestehende Testdateien nicht anzufassen, damit der Diff lesbar bleibt. Beim Ausführen kommt oft eine Überraschung: Für den Coverage-Bericht fehlt eine Abhängigkeit, und das Werkzeug will sie installieren. Das ist nützlich, aber eine bewusste Entscheidung — nicht etwas, das nebenbei passieren sollte.

3:10 Und am Ende steht der Schritt, den niemand auslassen darf: die erzeugten Tests fachlich lesen. Grün heißt noch nicht sinnvoll. Suchen Sie sich eine Funktion aus Ihrem eigenen Projekt — am besten eine mit Verzweigungen, also mit mehreren Wenn-Dann-Pfaden. Die Fähigkeit, die Sie üben, ist das Eingrenzen: Wie formuliere ich den Auftrag so, dass wirklich isolierte Tests entstehen und nicht ein Sammelsurium?

3:34 Ihr Erfolgskriterium ist doppelt — die Tests laufen ohne Datenbank und Netzwerk, und sie decken alle Zweige ab. Der zweite Teil ist der anspruchsvollere. Nutzen Sie den Coverage-Bericht, aber verlassen Sie sich nicht blind darauf: Ein durchlaufener Zweig ist noch kein geprüftes Verhalten. Drei Punkte, die Ihnen sicher begegnen.

3:53 Der erste ist eine Ordnungsfrage: Ohne klare Ansage schreibt das Werkzeug neue Tests in bestehende Dateien — und plötzlich lässt sich im Diff nicht mehr unterscheiden, was generiert wurde und was schon da war. Der zweite betrifft Abhängigkeiten: Werkzeuge installieren nach, wenn ihnen etwas fehlt. Das ist bequem und gehört trotzdem gesehen und freigegeben.

4:14 Und der dritte ist der wichtigste: Grüne Tests sagen nur, dass Erwartung und Verhalten übereinstimmen. Ob die Erwartung fachlich richtig war, prüft kein Testlauf — nur Sie.

Integrationstests aufsetzen

4:25 Eine Ebene höher wird es interessanter: Jetzt geht es nicht mehr um einzelne Funktionen, sondern um deren Zusammenspiel über mehrere Schichten hinweg. Und um eine Entscheidung, die über die Nützlichkeit der ganzen Testsuite bestimmt — nämlich, wogegen diese Tests eigentlich laufen. Gegen eine echte Umgebung oder gegen eine Datenbank im Arbeitsspeicher? Diese scheinbar technische Frage hat überraschend große Wirkung auf den gesamten Entwicklungsprozess.

4:51 Wenn wir hier von Integrationstests sprechen, meinen wir Whitebox-Tests im Quellcode: Sie prüfen, ob Controller, Service und Repository korrekt zusammenspielen. Das ist ausdrücklich etwas anderes als ein API-Test von außen. Der Vergleich, der hilft: Ein Unit-Test prüft, ob ein einzelnes Zahnrad rund läuft — ein Integrationstest prüft, ob das Getriebe greift.

5:12 Und das Entscheidende steckt in einem kleinen Detail: Diese Tests laufen gegen eine Datenbank im Arbeitsspeicher. Damit brauchen sie keine bereitgestellte Umgebung und laufen in jeder Build-Pipeline mit. Hier steckt der eigentliche Hebel dieses Kapitels. Wer Integrationstests gegen eine echte Umgebung fährt, kann sie erst ausführen, wenn diese Umgebung steht — also spät.

5:35 Wer sie im Arbeitsspeicher laufen lässt, bekommt die Rückmeldung sofort beim Build. Das ist gemeint, wenn von „Shift left" die Rede ist: Der Prüfpunkt wandert nach vorn, wo ein Fehler noch billig ist. Der schöne Nebeneffekt: Ein Fehlschlag kann das Deployment blockieren, bevor überhaupt etwas ausgeliefert wurde. Und es fällt eine Dauerbaustelle weg — das Aufräumen geteilter Testdaten zwischen Läufen.

6:00 Der wichtigste Gedanke steht in Schritt zwei: das öffentliche Verhalten testen, nicht die Implementierung. Sonst entstehen Tests, die bei jedem Refactoring rot werden, ohne dass etwas kaputt wäre — der schnellste Weg, ein Team gegen die eigene Testsuite aufzubringen. Der Rest ist Aufbauarbeit: Die Forderung nach einer In-Memory-Datenbank zieht Konfiguration und Abhängigkeiten nach sich, und genau das erledigt das Werkzeug gleich mit.

6:24 Rechnen Sie damit, dass der erste Testlauf nicht durchläuft — das ist normal, und die Korrekturschleife gehört zum Auftrag. Danach wird es deutlich einfacher. Diese Übung hat einen unscheinbaren Kern: die Grenzziehung. Bevor Sie irgendetwas erzeugen lassen, entscheiden Sie, was in Ihrem Fluss auf die Unit-Ebene gehört und was wirklich Integration ist.

6:45 Genau diese Entscheidung nimmt Ihnen kein Werkzeug ab — und wenn Sie sie nicht treffen, trifft das Modell sie für Sie, meist großzügig. Ihr Erfolgskriterium ist konkret: Persistenz und Abruf werden über alle Schichten geprüft, und der Test läuft ohne externe Datenbank. Wer schneller ist, lagert die Hilfsfunktionen aus — die werden Sie beim nächsten Test wieder brauchen.

7:07 Diese drei Punkte haben eine gemeinsame Ursache: fehlende Vorgaben. Ohne klare Abgrenzung testet das Werkzeug auf Integrationsebene mit, was eigentlich ein Unit-Test wäre — die Suite wird langsamer, ohne mehr zu prüfen. Ohne Hinweis auf Testdaten-Generatoren entstehen hartkodierte Werte, die beim zehnten Test zur Last werden.

7:27 Und der dritte Punkt ist eine Aufforderung zur Sorgfalt: Der Aufbau verändert Konfiguration und Abhängigkeiten des Projekts. Das ist gewollt — aber es ist Ihr Projekt. Lesen Sie den Diff, bevor Sie ihn übernehmen.

End-to-End-Tests im Browser

7:40 Jetzt kommen wir auf die Ebene, auf der Ihre Nutzer unterwegs sind — der Browser. Und wir gehen dabei einen ungewöhnlichen Weg: ohne jeden Blick in den Anwendungscode. Die KI erkundet die laufende Oberfläche selbst, ermittelt die Elemente und baut daraus ein Testprojekt von Grund auf. Das entspricht genau der Perspektive, aus der QA-Engineers seit jeher End-to-End-Tests entwerfen — man hat die Anwendung vor sich, nicht ihren Bauplan.

8:06 End-to-End bedeutet: Wir prüfen die Anwendung aus Nutzersicht, vom Klick bis zum angezeigten Ergebnis. Das Besondere ist, wie die KI hier zu ihrem Wissen kommt. Über eine Browser-Anbindung erkundet sie die laufende Anwendung selbst, ermittelt die Elemente und schreibt daraus Tests nach dem Page-Object-Modell — also mit sauber getrennten Seitenobjekten statt Selektoren quer durch den Testcode.

8:29 Und das alles ohne Zugriff auf den Quellcode. Genau so gehen QA-Engineers seit jeher an End-to-End-Tests: Man hat die Anwendung vor sich, nicht ihren Bauplan. Bei diesem Prompt kommt es auf drei Dinge an. Erstens die Struktur: Wer das Page-Object-Modell nicht ausdrücklich fordert, bekommt Selektoren mitten im Test — beim ersten Test egal, beim zwanzigsten ein Problem.

8:51 Zweitens der Fluss selbst, Schritt für Schritt beschrieben, so wie Sie ihn manuell durchklicken würden. Drittens — und das ist der eigentliche Stolperdraht — die Ansage, den Browser zu benutzen. Ohne diesen Hinweis versucht das Werkzeug, die Anwendung per Kommandozeile abzurufen, und bekommt HTML statt einer gerenderten Seite. Da hilft nur: hinschauen und korrigieren.

9:14 Der Trick in Schritt eins ist bewusst kontraintuitiv: ein leeres Projekt. Wer der KI den Anwendungscode gibt, bekommt Tests, die aus dem Code abgeleitet sind — und damit dieselben Annahmen wiederholen. Ohne Code bleibt nur die Oberfläche als Quelle, und genau das wollen wir. Rechnen Sie beim Zuschauen mit Kurskorrekturen; die erste Richtung stimmt selten.

9:35 Und der letzte Schritt ist eine Investition: Der erste stabile Test wird zur Vorlage für alle weiteren. Was Sie hier an Struktur nicht nachschärfen, schleppen Sie durch die gesamte Suite. Die Logik dahinter ist eine Pyramide, und sie erklärt, warum man nicht alles auf einer Ebene testen sollte. Unit-Tests sind billig und schnell grün, prüfen aber nur kleine Ausschnitte. Integrationstests kosten einmalig Aufbau und sind danach leicht zu vermehren.

10:02 End-to-End-Tests sind die teuersten und langsamsten — und zugleich die einzigen, die zeigen, ob es für den Nutzer funktioniert. Die praktische Konsequenz: viele Tests unten, wenige oben. Wer das umdreht, bekommt eine Suite, die lange läuft, oft grundlos rot wird — und der irgendwann niemand mehr glaubt. Nehmen Sie einen Fluss, den Sie ohnehin regelmäßig manuell prüfen.

10:25 Die Fähigkeit, die hier zählt, ist Struktur: Der Test soll nicht nur einmal durchlaufen, sondern morgen erweiterbar sein. Zwei Dinge machen den Unterschied und stehen deshalb im Erfolgskriterium. Erstens Page Objects — die Interaktion mit der Oberfläche gehört an eine Stelle, nicht in jeden Test. Zweitens der Ausgangszustand: Ein Test, der auf vorhandene Daten trifft, ist beim zweiten Lauf ein anderer Test.

10:50 Wer das nicht löst, hat keine Automatisierung, sondern eine Fehlerquelle. Diese drei Punkte trennen ein Demo-Ergebnis von einer echten Testsuite. Hartkodierte Testdaten machen den Test blind für Datenvariationen — er prüft dann immer denselben Sonderfall. Der fehlende Reset ist die häufigste Ursache für Tests, die beim zweiten Lauf scheitern und dann als „instabil" abgestempelt werden, obwohl schlicht der Zustand nicht stimmt.

11:15 Und der dritte Punkt fasst das ganze Modul zusammen: Prompten allein reicht nicht. Sie müssen wissen, wie das Projekt am Ende aussehen soll — sonst optimieren Sie ein Ergebnis, für das Sie kein Zielbild haben. Über alle drei Ebenen hinweg wiederholen sich dieselben vier Muster. Der Plan-Modus vor Codeänderungen spart mehr Zeit, als er kostet.

11:35 Kleine Aufgaben mit Beispielen liefern verlässlicher gute Ergebnisse als große offene Aufträge. Der erste Test einer Ebene prägt alle folgenden — deshalb lohnt es sich, genau dort Struktur nachzuschärfen. Und der vierte Punkt ist der, der sich durch das ganze Seminar zieht: Ob ein Test fachlich etwas taugt, entscheidet kein Testlauf. Grün ist ein Zustand, keine Qualitätsaussage.

Testautomatisierung beschleunigen

11:59 Das Bemerkenswerte an diesem Modul war nicht, dass die KI Tests schreibt — das war zu erwarten. Bemerkenswert ist, dass sie unterwegs fehlende Infrastruktur aufbaut: das Coverage-Setup, die In-Memory-Datenbank, das gesamte End-to-End-Projekt. Genau dort liegt oft die eigentliche Hürde. Und der Gewinn wächst mit der Qualität Ihrer Vorgaben, nicht mit der Länge des Prompts.

12:20 Im nächsten Modul verlassen wir das funktionale Testen und wenden dieselben Techniken auf Bereiche an, die vielen QA-Teams bisher verschlossen blieben: Performance, Fuzzing, Barrierefreiheit und Lokalisierung.