Testabdeckung strategisch ausbauen

Testabdeckung strategisch ausbauen

0:00 Mit Agenten ist es leicht geworden, mehr Tests zu erzeugen. Genau darin liegt die neue Gefahr: Eine Suite kann wachsen, ohne dass die Absicherung mitwächst. In diesem Modul geht es deshalb nicht um Menge, sondern um Auswahl. Wir schauen uns an, wie man Lücken systematisch findet, wie aus einer Anforderung ein prüfbares Szenario wird, wie die API die Vorbereitung übernimmt — und wie man aus den Artefakten eines Laufs Dinge herausliest, die kein Test behauptet hat.

Lücken in der Abdeckung finden

0:27 Zuerst die Bestandsaufnahme. Und gleich vorweg: Wir reden nicht über Codeabdeckung. Die Frage lautet anders — und sie ist schwieriger zu beantworten. Die Antwort auf die Frage, wie gut eine Suite absichert, steht in keiner Kennzahl. Sie entsteht durch eine Bestandsaufnahme, und die machen wir uns in diesem Kapitel so einfach wie möglich.

0:48 Abdeckung heißt hier: Welche Anforderungen, Rollen und Zustände sind durch mindestens einen Test abgesichert? Nicht, wie viele Zeilen Code durchlaufen wurden — diese Zahl sagt bei Oberflächentests ohnehin wenig. Die Lücke findet man, indem man ein Inventar der vorhandenen Tests gegen eine Liste der Risiken hält. Das ist Handarbeit, aber es ist die Handarbeit, die zählt.

1:10 Und es ist ausdrücklich nicht die Aufgabe, die man an einen Agenten delegiert, indem man mehr erzeugen lässt. Fünf Schritte. Testinventar erstellen: Welcher Test sichert welche Regel ab? Wer das zum ersten Mal macht, erlebt eine Überraschung — für manchen Test lässt sich die Frage nicht beantworten. Anforderungen und bekannte Fehler danebenlegen.

1:32 Rollen und Zustände ergänzen, die bisher nie vorkamen. Je Lücke das Risiko schätzen, also Häufigkeit mal Schaden. Und dann nur die obersten Lücken beauftragen — der Rest wird sichtbar zurückgestellt. Sichtbar ist das entscheidende Wort: Zurückgestellt ist eine Entscheidung, vergessen nicht. Was diese Tabelle wertvoll macht, ist die dritte Spalte. Sie zeigt nicht, wie viel wir haben, sondern was fehlt — und genau das ist die Information, mit der man arbeitet.

2:00 Beachten Sie die Zeile mit der Gärtnerin: Diese Lücke existiert nicht, weil jemand nachlässig war, sondern weil kein Testkonto für diese Rolle eingerichtet ist. Solche organisatorischen Lücken finden Sie nur mit einem Inventar; ein Agent findet sie prinzipiell nicht. Und die Fußnote gilt: Diese Spalte trägt die Priorisierung, sie ist wichtiger als jede Prozentzahl.

2:22 Vier blinde Flecken, und alle vier haben denselben Grund: Sie entstehen nicht von selbst. Negativfälle und Grenzwerte fehlen, weil der Happy Path zuerst geschrieben wird und danach die Zeit knapp ist. Rollen fehlen, weil kein Zugang existiert. Zustände nach Abbruch, Zurück-Navigation oder Neuladen fehlen, weil niemand so testet — echte Benutzer aber schon.

2:43 Und Darstellung auf schmalen Fenstern und Bedienung ohne Maus fehlen, weil sie als Sonderthema gelten. Sind sie nicht: Barrierefreiheit ist ein Qualitätsmerkmal wie Ladezeit. Vier Denkfehler rund um Abdeckung. Sie an der Zahl der Tests zu messen ist der verbreitetste — und mit Agenten der gefährlichste, weil die Zahl jetzt beliebig wächst.

3:03 Denselben Happy Path in drei Browsern zu zählen, als wären es drei Regeln, schönt die Statistik. Lücken zu finden und nicht zu dokumentieren, weil gerade keine Zeit ist, macht die halbe Arbeit umsonst. Und Barrierefreiheit als Sonderthema zu behandeln, verschiebt sie auf einen Zeitpunkt, der nie kommt.

Tests aus Spezifikationen ableiten

3:22 Damit zur Gegenrichtung: nicht von den Tests zu den Lücken, sondern von der Anforderung zum Test. Hier kann ein Agent tatsächlich viel abnehmen. Diese Richtung ist die angenehmere, weil sie mit etwas Geschriebenem beginnt. Und sie ist der Teil, bei dem ein Agent tatsächlich viel Fleißarbeit abnehmen kann. Wichtig bleibt nur, wer am Ende entscheidet, welche Szenarien tatsächlich entstehen.

3:45 Eine Spezifikation wird testbar, wenn sich aus ihr ein Szenario mit Ausgangszustand, Handlung und beobachtbarem Ergebnis ableiten lässt. Diese Übersetzung ist Fleißarbeit — und genau die kann ein Agent gut vorbereiten. Er liest ein Ticket und schlägt fünf Szenarien vor, in Minuten. Was er nicht entscheiden kann, ist, welche davon tatsächlich entstehen: Das hängt an Risiko, Aufwand und daran, was das Team ohnehin schon abgesichert hat.

4:12 Vorbereiten kann er, entscheiden müssen Sie. Fünf Zeilen — das ist die kleinste Form, mit der Planner und Generator zuverlässig arbeiten. Regel, Zustand, Handlung, Erwartung, Daten. Was auf den ersten Blick nach Bürokratie aussieht, ist in Wahrheit eine Denkhilfe: Wer diese fünf Zeilen nicht ausfüllen kann, hat die Anforderung noch nicht verstanden.

4:34 Besonders die letzte Zeile trennt gute von schlechten Szenarien. „Ein Gutschein mit Ablaufdatum in der Vergangenheit" ist eine Datenanforderung, die man erfüllen kann. „Ein ungültiger Gutschein" ist es nicht. Vier Situationen, in denen sich die Kette Anforderung, Plan, Test auszahlt. Bei einem Fehlschlag ist sofort klar, welche Regel betroffen ist — Sie sparen den Umweg über den Code.

4:58 Bei einer Änderung der Anforderung finden Sie die betroffenen Tests, ohne zu suchen. Doppelte Szenarien fallen auf, weil sie auf dieselbe Regel zeigen. Und Diskussionen über Abdeckung werden konkret statt gefühlt. Der Aufwand dafür ist eine Zeile Verweis pro Szenario. Selten war ein so kleiner Aufwand so gut angelegt. Fünf Schritte, um aus einem Vorschlagsberg eine Arbeitsliste zu machen. Szenarien der gleichen Regel zuordnen und Duplikate zusammenführen.

5:27 Szenarien ohne Regel streichen — oder eine Regel dafür klären, falls sich dahinter etwas Echtes verbirgt. Grenzfälle ergänzen, die aus der Regel folgen, aber nie sichtbar waren; das ist der Punkt, an dem ein Mensch dem Agenten überlegen ist. Nach Risiko sortieren. Und den Verweis aufs Ticket in Plan und Testnamen aufnehmen. Nach zwanzig Minuten haben Sie aus dreißig Vorschlägen zwölf brauchbare Szenarien.

API-gestütztes Testen

5:53 Jetzt zu einem Hebel, der die Stabilität einer Suite oft mehr verbessert als jede Locator-Diskussion: die Schnittstelle statt der Oberfläche für alles, was nur Vorbereitung ist. Dieses Kapitel ist der stille Favorit vieler Teams: wenig Aufwand, große Wirkung auf Laufzeit und Stabilität. Es geht darum, die Oberfläche nur noch für das zu benutzen, wofür sie da ist.

6:15 Playwright kann HTTP-Aufrufe unabhängig vom Browser ausführen. Damit lassen sich eigenständige API-Tests schreiben — vor allem aber Ausgangszustände herstellen und Ergebnisse nachprüfen, ohne den Umweg über die Oberfläche. Und ein Detail, das vieles vereinfacht: Der Anmeldezustand ist zwischen beiden Welten austauschbar.

6:33 Sie können sich also über die API anmelden und mit derselben Sitzung im Browser weiterarbeiten. Das spart in einer großen Suite mehr Zeit als jede andere Einzelmaßnahme. Das Muster in diesem Beispiel ist einfach und wirkungsvoll: Die Bestellung entsteht per Schnittstellenaufruf, geprüft wird in der Oberfläche. Der Kassendurchlauf über Formulare hätte Sekunden gedauert und an fünf Stellen wackeln können — der Aufruf dauert Millisekunden und kann es nicht.

7:00 Wichtig ist, was dabei nicht verloren geht: Die eigentliche Prüfung findet weiterhin dort statt, wo die Benutzerin hinschaut. Sie verlagern die Vorbereitung, nicht die Aussage. Die Regel hinter dieser Tabelle steht in der Fußnote und lässt sich gut merken: Über die Oberfläche nur das prüfen, was auch ein Mensch dort prüfen würde.

7:19 Alles andere — Ausgangszustände herstellen, Nachbedingungen kontrollieren, fremde Dienste ausschalten — ist über die Schnittstelle schneller und stabiler. Der vierte Punkt, das Abfangen von Netzwerkaufrufen, verdient eine Warnung: Er ist mächtig und verführt dazu, am Ende nur noch die eigenen Antworten zu testen. Dann ist die Suite grün und sagt nichts mehr über das echte System.

7:40 Vier Punkte. Den Kassendurchlauf in jedem Test zu wiederholen kostet Laufzeit und Stabilität — das ist der Fall, für den es die Schnittstelle gibt. Über die API Zustände zu bauen, die es fachlich gar nicht geben kann, produziert Tests, die nichts über die Realität aussagen. Alles abzufangen führt zur Selbstbestätigung, wie eben besprochen.

8:00 Und Zugangsdaten in die Testdatei zu schreiben ist derselbe Fehler wie in Modul vier — er passiert bei API-Tests nur besonders oft, weil das Token so praktisch zur Hand ist.

Exploratives Testen mit Artefakten

8:11 Zum Abschluss eine Quelle, die in fast jedem Projekt ungenutzt herumliegt: das Material, das jeder Testlauf ohnehin produziert. Jeder Lauf hinterlässt Material, das in den meisten Projekten ungelesen bleibt. Dabei steht darin oft mehr, als alle Tests zusammen behaupten — man muss nur hinschauen lassen. Und Agenten sind genau darin stark: Sie ermüden beim Durchsehen von Protokollen nicht.

8:35 Jeder Lauf hinterlässt Screenshots, Videos, Traces, Accessibility Snapshots, Netzwerk- und Konsolenausgaben. Üblicherweise schaut man da nur hinein, wenn etwas rot ist. Dabei steckt in einem grünen Lauf oft mehr Information als in einem roten — nämlich alles, was passiert ist, ohne dass ein Test es behauptet hat. Ein Konsolenfehler bei grünem Lauf ist so ein Fall.

8:57 Und genau hier sind Agenten stark: Sie ermüden nicht beim Durchsehen von Protokollen, und sie haben keine Erwartung, die den Blick lenkt. Vier Artefakte, vier Fragen. Traces zeigen Aktion, Zustand und Netzwerk in einer gemeinsamen Zeitachse — sie beantworten das Was und das Warum zusammen. Accessibility Snapshots legen fehlende Rollen und Namen offen, also genau die Mängel, die auch Ihre Locators brüchig machen.

9:23 Konsolenfehler weisen auf Probleme hin, die die Oberfläche verschweigt. Und visuelle Vergleiche finden Verschiebungen, die keine Assertion prüft. Zusammengenommen ist das eine Diagnoselage, die man von Hand nie systematisch auswerten würde. Fünf Schritte, und zwei davon sind Qualitätssicherung. Erst Traces und Berichte eines vollständigen Laufs bereitstellen.

9:46 Dann nach Auffälligkeiten fragen — ausdrücklich nicht nach einer Zusammenfassung, sonst bekommen Sie schöne Prosa. Zu jeder Auffälligkeit Belegstelle und Zeitpunkt verlangen. Dann die Befunde gegen die Anforderung prüfen, bevor daraus Tests werden; sonst zementieren Sie wieder den Ist-Zustand. Und erst bestätigte Befunde wandern als Szenarien in den Plan. Diese Reihenfolge kennen Sie inzwischen — sie ist das Muster des ganzen Seminars.

10:13 Ihre Aufgabe: Leiten Sie aus den Artefakten eines Laufs eine belegte Auffälligkeit ab und formulieren Sie sie prüfbar. Das Erfolgskriterium verlangt einen Verweis auf eine Fundstelle — im Trace oder in der Konsolenausgabe. Und noch ein Hinweis, der ernst gemeint ist: Auch ein Befund ohne Testfall ist ein Ergebnis. Nicht alles, was auffällt, muss automatisiert werden; manches gehört einfach als Hinweis ins Ticket.

10:37 Im nächsten Modul wird es dann technischer — es geht um Parallelität und darum, warum Tests in der Gruppe anders reagieren als allein.