Testfälle mit GenAI

Testfälle mit GenAI

0:00 Testfälle zu schreiben ist die klassische Fleißarbeit der QA: nicht schwer, aber zeitraubend, und mit jedem Release wächst der Berg, den man pflegen muss. Genau hier zeigt generative KI ihre auffälligste Wirkung — sie liefert in Sekunden, wofür man einen halben Tag eingeplant hatte. Nur ist Menge nicht dasselbe wie Qualität.

0:19 In diesem Modul gehen wir beide Wege durch: einmal aus Anforderungen abgeleitet, einmal aus der laufenden Anwendung erkundet. Und wir schauen genau hin, wo aus vielen Testfällen wenige gute werden.

Testfälle aus Anforderungen

0:31 Beginnen wir mit dem naheliegenden Weg: Wir haben eine User Story mit Akzeptanzkriterien und lassen daraus Testfälle entstehen. Klingt einfach — und ist es auch. Die interessante Arbeit beginnt erst danach: beim Verdichten, beim Prüfen auf Annahmen und beim Nachweis, dass jedes Kriterium tatsächlich abgedeckt ist. Genau diese drei Schritte gehen wir in diesem Kapitel durch, bis am Ende ein Satz steht, den man auch in einem halben Jahr noch pflegen möchte.

0:57 Unsere Grundlage ist eine ganz normale User Story: Ein Nutzer erfasst ein Lebensmittel mit Grammangabe und Mahlzeitentyp und sieht das Ergebnis auf dem Dashboard. Dazu die Akzeptanzkriterien — nur positive Mengenangaben, Einträge für heute oder vergangene Tage, gelöschte Einträge verschwinden auch aus der Übersicht. Das Modell bekommt eine Rolle, diese Story und ein festes Ausgabeformat. Wichtig ist dieses Format: Titel, Vorbedingung, Schritte, Testdaten, Erwartung.

1:25 Ohne Formatvorgabe bekommen Sie Prosa, die sich hübsch liest und in kein Testmanagement-Tool passt. Worauf es hier ankommt, sind zwei Bewegungen. Die erste ist das Ausgabeformat — je genauer Sie beschreiben, welche Felder Sie erwarten, desto weniger müssen Sie hinterher umbauen. Die zweite ist die Verbotszeile am Ende, und die ist interessanter: Wir sagen dem Modell nicht nur, dass es keine Annahmen treffen soll, sondern wohin es mit Unsicherheit gehen darf — nämlich in eine Markierung.

1:54 Ohne diesen Ausweg füllt es Lücken einfach auf, und Sie bekommen Testdaten für Lebensmittel, die es in der Anwendung nie gab. Ein Verbot ohne Alternative verpufft. Vierzig Testfälle für eine einzige User Story — das ist eine ehrliche Zahl aus der Praxis, und sie beschreibt das Problem ziemlich genau. Die Happy Paths sind tatsächlich sauber, inklusive der Prüfung, ob sich das Dashboard aktualisiert.

2:18 Es tauchen sogar nützliche Fälle auf, die in den Kriterien gar nicht stehen — Dezimalwerte bei der Grammangabe zum Beispiel. Das ist der Gewinn. Der Preis steht daneben: Dieselbe Erwartung erscheint an anderer Stelle noch einmal als eigener Testfall. Vierzig Fälle bedeuten vierzig Artefakte, die bei jeder Änderung gepflegt werden wollen. Menge ist hier ein Kostenfaktor.

2:41 Der rote Faden dieser fünf Schritte lautet: erst Breite erzeugen, dann verdichten. Von vierzig auf siebzehn — das klingt nach Verlust, ist aber keiner, solange nur Redundanz verschwindet. Genau das ist der Prüfpunkt in Schritt drei, und er gehört Ihnen, nicht dem Modell. Danach kommt ein oft übersehener Schritt: das Zielformat vorgeben, samt Beispielwerten.

3:03 Wer nur sagt „gib mir JSON", bekommt JSON mit erfundenen Feldwerten. Wer Beispielwerte mitliefert, bekommt etwas, das sich direkt importieren lässt. Und zum Schluss die Coverage-Matrix — der Beleg, dass die Verdichtung nichts gekostet hat. Das Prinzip hinter dieser Aufstellung ist eine Arbeitsteilung in Etappen. Kein einzelner Prompt liefert alles auf einmal — und das sollte er auch nicht.

3:27 Jeder Schritt hat eine klar umrissene Aufgabe: Der erste erzeugt Breite und darf ruhig redundant sein. Der zweite verdichtet. Der dritte macht das Ergebnis maschinenlesbar. Und der vierte belegt, dass unterwegs nichts verloren ging. Wer versucht, das alles in einen einzigen langen Prompt zu packen, bekommt ein Ergebnis, das an jeder Stelle ein bisschen ungenau ist.

3:49 Kleine Schritte sind hier nicht umständlich, sondern präziser. Jetzt sind Sie an der Reihe — und die Aufgabe ist bewusst eine Reduktionsübung. Nehmen Sie einen generierten Satz und bringen Sie ihn auf ein Maß, das Sie in einem Jahr noch pflegen wollen. Die Fähigkeit dahinter: unterscheiden, was wirklich ein anderer Testfall ist und was derselbe Gedanke in neuer Verpackung.

4:11 Ihr Erfolgskriterium ist überprüfbar, nicht nach Gefühl — jedes Akzeptanzkriterium muss weiterhin mindestens einmal abgedeckt sein, und die Coverage-Matrix beweist es. Wer schneller fertig ist, bringt das Ergebnis in das Format des eigenen Testmanagement-Tools. Diese drei Fallen kosten in der Praxis am meisten Zeit. Die erste betrifft Feldwerte: Wenn Sie ein Zielformat vorgeben, ohne erlaubte Werte zu nennen, erfindet das Modell eigene — plötzlich steht im Typ-Feld etwas, das Ihr Tool nicht kennt.

4:40 Beispielwerte sind die Lösung, nicht längere Beschreibungen. Die zweite ist die Mengenfalle, über die wir schon gesprochen haben — sie schlägt erst Monate später zu. Und die dritte ist besonders ärgerlich: Das Modell formuliert die Akzeptanzkriterien beim Mappen leicht um, und schon stimmt die Zuordnung nicht mehr. Sagen Sie ausdrücklich, dass sie unverändert bleiben.

Testfälle aus Live-Exploration

5:02 Jetzt drehen wir die Richtung um. Statt aus Dokumenten abzuleiten, lassen wir die KI die laufende Anwendung selbst erkunden — so, wie es ein neuer Kollege am ersten Tag tun würde: klicken, ausprobieren, beobachten. Das braucht eine andere Werkzeugkette als bisher und liefert Testfälle von anderer Art. Vor allem aber findet dieser Weg Dinge, die in keinem Anforderungsdokument stehen.

5:25 Schauen wir uns an, wie das praktisch abläuft. Hier steuert ein KI-Agent die Anwendung tatsächlich im Browser: klickt, tippt, beobachtet — und leitet daraus Testfälle ab. Der praktische Unterschied zum bisherigen Vorgehen ist entscheidend: Ein reines Chat-Fenster im Web kann das nicht. Sie brauchen ein Werkzeug, das lokal läuft und Zugriff auf einen Browser hat.

5:46 Stellen Sie sich das vor wie den Unterschied zwischen jemandem, der die Bedienungsanleitung liest, und jemandem, der sich vor das Gerät setzt und die Knöpfe drückt. Beide lernen etwas — aber nicht dasselbe. Der wichtigste Schritt in dieser Kette ist der dritte: der Scope. Wer ihn weglässt, bekommt eine Erkundung der kompletten Anwendung — beeindruckend anzusehen, aber selten das, was man wollte.

6:09 Interessant ist auch Schritt zwei: Statt dem Agenten Zugangsdaten in den Prompt zu schreiben, meldet man sich selbst an und lässt ihn die bestehende Browser-Sitzung weiterverwenden. Das ist nicht nur sauberer, es umgeht auch Zwei-Faktor-Authentifizierung und Captchas, an denen jeder Automatisierungsversuch sonst scheitert.

6:27 Und schauen Sie beim Laufen zu — die protokollierten Beobachtungen sind oft aufschlussreicher als das Endergebnis. Hier liegt der eigentliche Mehrwert dieses zweiten Wegs. In unserem Beispiel fand der Agent nebenbei einen echten Fehler: Ein eigenes Lebensmittel lässt sich anlegen, aber das Bearbeiten speichert nicht. Kein Akzeptanzkriterium hätte darauf hingewiesen, denn Anforderungen beschreiben, was funktionieren soll — nicht, was kaputt ist.

6:54 Dazu kamen Barrierefreiheitsmängel, etwa Icon-Buttons ohne zugänglichen Namen. Das ist der Unterschied zwischen Ableiten und Hinschauen. Wer nur aus Dokumenten testet, findet nie das, was in keinem Dokument steht. Die Logik dieser Gegenüberstellung: Beide Wege haben eine Stärke, und beide haben genau dort ihre Schwäche, wo der andere stark ist.

7:15 Aus Anforderungen entstehen präzise Testfälle mit vollständiger Kriterienabdeckung — aber nur für das, was jemand aufgeschrieben hat. Aus der Exploration entstehen gröbere Testfälle, dafür gegen die Realität geprüft. Auch die Risiken spiegeln sich: Der eine Weg erfindet Testdaten, der andere läuft ohne Grenzen aus dem Ruder. Deshalb ist die Frage nicht, welcher Weg besser ist.

7:37 Die Frage ist, wie man sie kombiniert. In dieser Übung geht es weniger um das Ergebnis als um die Eingrenzung. Wählen Sie ein einzelnes Feature — nicht die ganze Anwendung — und formulieren Sie den Auftrag so, dass der Agent dort bleibt. Genau das ist die Fähigkeit, die Sie trainieren: eine explorative Session so zuschneiden, dass verwertbare Testfälle herauskommen statt einer Sightseeing-Tour.

8:01 Ihr Ergebnis ist zweiteilig — die Testfälle selbst und eine Liste der Auffälligkeiten, die dem Agenten unterwegs begegnet sind. Erfahrungsgemäß ist die zweite Liste die interessantere. Drei Punkte, die in der Praxis regelmäßig auftauchen. Der Scope kennen Sie inzwischen — ohne Grenze wird die ganze Anwendung erkundet, und die Session dauert deutlich länger als geplant.

8:23 Beim zweiten Punkt geht es um Hygiene: Zugangsdaten im Prompt sind bei einer Demo-Anwendung unkritisch, in einem echten Projekt aber der falsche Reflex. Die geteilte Sitzung ist der bessere Weg. Und der dritte Punkt ist eine Erwartungshaltung: Explorative Testfälle sind gröber als anforderungsbasierte. Das ist kein Mangel, sondern liegt in der Natur der Quelle — die laufende Anwendung erklärt nicht, was sie soll.

8:47 Wenn Sie aus diesem Modul eine Sache mitnehmen, dann diese: Die beiden Wege sind keine Alternativen, sondern Ergänzungen. Anforderungen sichern die Abdeckung — sie garantieren, dass kein Akzeptanzkriterium unter den Tisch fällt. Die Exploration findet das, was in keinem Dokument steht. Der praktische Trick, der beides verbindet, ist ein einziger Prompt: Geben Sie dem Werkzeug die Anforderungen und fragen Sie, was darüber hinaus noch geprüft werden sollte.

9:14 Bewerten müssen Sie das Ergebnis trotzdem — aber Sie starten dann von einer deutlich breiteren Basis.

Testfälle mit GenAI

9:20 Fassen wir zusammen: Erst Breite erzeugen, dann gezielt auf ein Maß reduzieren, das man pflegen kann — und dabei mit einer Coverage-Matrix belegen, dass nichts verloren ging. Wer zusätzlich Format und Beispielwerte vorgibt, spart sich die gesamte Nacharbeit beim Import. Im nächsten Modul gehen wir einen Schritt weiter: Aus Testfällen wird ausführbarer Code.

9:41 Wir lassen Unit-Tests, Integrationstests und End-to-End-Tests erzeugen — und sehen dabei, dass die KI nicht nur Tests schreibt, sondern auch die Infrastruktur, die bislang fehlte.