Nichtfunktionale Tests mit GenAI

Nichtfunktionale Tests mit GenAI

0:00 Performance, Fuzzing, Barrierefreiheit, Lokalisierung — das sind die Bereiche, die in vielen QA-Teams schlicht nicht stattfinden. Nicht aus Desinteresse, sondern weil jeder davon eigenes Spezialwissen verlangt, das man sich neben dem Tagesgeschäft kaum aneignet. Genau hier ist generative KI mehr als eine Beschleunigung: Sie macht diese Bereiche überhaupt erst zugänglich. In diesem Modul gehen wir alle vier durch.

0:24 Und es zieht sich ein Muster hindurch, das Sie sich merken sollten: Die Messung übernehmen weiterhin deterministische Werkzeuge — die KI erklärt, ordnet ein und priorisiert.

Performance-Tests erzeugen und deuten

0:35 Beginnen wir mit der Frage, die vor jedem Release im Raum steht: Hält das eigentlich, wenn echte Nutzer draufgehen? Wir übersetzen dafür einen realen Nutzerfluss in ein Lastszenario, fahren die Anwendung schrittweise an ihre Grenze — und lassen uns das Ergebnis anschließend erklären. Genau dieser letzte Teil ist der interessante: aus Latenzkurven und Fehlerraten Sätze zu machen, mit denen ein ganzes Team etwas anfangen kann.

0:59 Der Unterschied zwischen Last- und Stresstest ist schnell erklärt und im Alltag oft verwischt. Der Lasttest fragt: Hält die Anwendung, was wir an Nachfrage erwarten? Der Stresstest geht bewusst darüber hinaus und sucht die Grenze — ab wann wird es langsam, ab wann kommen Fehler, ab wann bringt mehr Last nichts mehr? Denken Sie an eine Brücke: Die eine Prüfung zeigt, dass der normale Berufsverkehr trägt. Die andere sucht die Belastung, bei der es kritisch wird.

1:26 Beide Antworten braucht man — und die zweite ist die, die vor bösen Überraschungen schützt. Der interessanteste Beitrag steht nicht am Anfang, sondern am Ende dieser Liste. Ein Lastszenario zu erzeugen, ist die kleinere Leistung — Skripte gibt es zuhauf. Wertvoll wird es dort, wo aus Messwerten Aussagen werden. Ein Bericht mit Latenzkurven ist für Spezialisten lesbar; die Aussage „ab sechzehn parallelen Nutzern reißt die Latenzgrenze, wahrscheinlich weil der Endpunkt zu viele Zeilen lädt" versteht das ganze Team.

1:56 Genau diese Übersetzung von Rohzahlen in Handlungsempfehlungen ist der Punkt, an dem Performance-Testing aus der Spezialistenecke herauskommt. Worauf es hier ankommt, sind zwei Dinge. Erstens die Zweiteilung: ein Skript, das Testdaten erzeugt, und eines, das die Last fährt. Ohne realistische Datenmenge messen Sie nämlich eine leere Datenbank — und die ist immer schnell. Zweitens die Abbruchregeln, und die sind der eigentliche Kniff.

2:23 Ohne sie läuft der Test entweder ewig oder bis zum Absturz. Mit ihnen sucht er gezielt die Grenze: Latenz über dem Schwellwert, zu viele Fehler, oder Durchsatz stagniert, während die Antwortzeiten steigen. Das dritte Kriterium ist das aussagekräftigste — es beschreibt genau den Punkt, an dem Skalierung aufhört zu wirken.

2:43 Ein Detail in diesem Ablauf verdient Aufmerksamkeit: Das Lastskript erzeugt die KI, gestartet wird es von Ihnen. Das ist kein Misstrauen, sondern Praxis — Sie wollen kontrollieren, wann Last auf ein System geht. Ebenso wichtig ist der dritte Schritt: Ergebnisse als Datei ablegen, nicht im Terminal lesen. Erst dadurch wird die Auswertung wiederholbar und vergleichbar.

3:05 Und beim letzten Schritt sind Sie gefragt: In unserem Beispiel war eine der Empfehlungen schlicht gegenstandslos, weil sie sich auf den Entwicklungsmodus bezog. Empfehlungen sind Vorschläge, keine Befunde. Suchen Sie sich einen Endpunkt, der viel liest und aggregiert — dort liegen die interessanten Grenzen. Die Fähigkeit, die Sie hier üben, ist die Übersetzung: von einem Nutzerfluss, den Sie kennen, zu einem Lastszenario mit belastbaren Abbruchkriterien.

3:32 Genau die Kriterien sind der anspruchsvolle Teil, denn sie verlangen eine Entscheidung: Was ist für dieses Produkt noch akzeptabel? Ihr Ergebnis ist ein Bericht, aus dem zwei Zahlen hervorgehen — die letzte gesunde Laststufe und der erste Einbruch. Diese beiden Werte sind es, die später in einem Release-Gespräch tatsächlich helfen.

3:51 Drei Punkte, die den Wert einer Messung zunichtemachen können. Ohne Abbruchregeln läuft der Test ins Leere — er wird irgendwann beendet, aber Sie wissen nicht, ob Sie die Grenze überhaupt erreicht haben. Der zweite Punkt betrifft Empfehlungen: Die KI kennt Ihren Betrieb nicht und schlägt gelegentlich etwas vor, das bei Ihnen längst anders läuft.

4:11 Und der dritte ist der wichtigste — eine Messung auf dem eigenen Rechner ist ein Anhaltspunkt, keine Aussage über Produktion. Andere Hardware, anderes Netz, andere Datenmenge. Nehmen Sie die Erkenntnis mit, nicht die absolute Zahl.

Fuzz-Tests gegen Invarianten

4:25 Jetzt zu einer Technik, die viele nur vom Hörensagen kennen — und die mit KI-Unterstützung plötzlich in Reichweite rückt: das gezielte Zerschießen eines Endpunkts mit unerwarteten Eingaben. Der Reiz liegt darin, dass wir nicht hunderte Testfälle schreiben, sondern eine einzige Regel formulieren, die immer gelten muss. Den Rest übernimmt das Werkzeug.

4:45 Und die Vorarbeit — die Suche nach der richtigen Regel — macht die KI. Fuzz-Testing sucht Eingaben, mit denen ein System nicht sicher umgeht — nicht, um zu beweisen, dass alles funktioniert, sondern um das Gegenteil zu versuchen. Der elegante Teil ist die Invariante: eine einzige Regel, die immer gelten muss, egal was hereinkommt.

5:05 Zum Beispiel: Ein fehlgeschlagener Aufruf darf nichts in der Datenbank hinterlassen. Das Werkzeug erzeugt dann Hunderte Eingabevarianten und prüft nur diese eine Regel. Der Vorteil dieses Ansatzes: Wenn die Regel bricht, haben Sie nicht nur einen Fehler, sondern einen konkreten Eingabefall, den Sie nachstellen können. Der entscheidende Schritt ist der erste — und der ist kontraintuitiv: noch kein Testcode. Stattdessen lassen wir das Werkzeug den Endpunkt lesen und riskante Annahmen benennen.

5:35 In unserem Beispiel kam dabei etwas ans Licht, das kein Testfall aus den Anforderungen gefunden hätte: Zutaten und Allergene werden gespeichert, bevor das Lebensmittel selbst geschrieben wird — und das ohne Transaktion. Schlägt der letzte Schritt fehl, bleiben verwaiste Datensätze zurück. Diese Analyse ist der eigentliche Erkenntnisgewinn. Der Fuzz-Test danach liefert nur noch den Beweis.

5:58 Das Prinzip hinter dieser Aufstellung: Eine gute Invariante ist einfach zu formulieren und schwer zu erfüllen. „Ein Fehlschlag hinterlässt keine Spuren" — diesen Satz versteht jeder, und genau deshalb taugt er als Prüfregel. Die zweite Spalte ist die interessantere: Sie begründet, warum ausgerechnet diese Regel gefährdet ist. Fehlende Transaktion, fehlende Bereichsprüfung, fehlende Validierung.

6:20 Merken Sie sich das Muster für Ihre eigenen Endpunkte: Suchen Sie nach Stellen, an denen mehrere Schreibvorgänge nacheinander passieren, und fragen Sie, was beim Abbruch in der Mitte übrig bleibt. In dieser Übung sind Sie in der Rolle des Angreifers — mit einem klaren Ziel. Formulieren Sie für einen Endpunkt Ihrer Wahl eine Invariante, die so einfach ist, dass jeder im Team sie versteht. Dann lassen Sie das Fuzzing darauf los.

6:46 Beide Ausgänge sind ein gültiges Ergebnis: entweder ein konkreter Payload, der die Regel bricht — dann haben Sie einen belegten Fehler mit Reproduktion —, oder ein begründeter Hinweis auf Stabilität. Wichtig ist die Formulierung „begründet": Hunderte bestandene Läufe sind ein gutes Zeichen, aber kein Beweis. Diese drei Punkte betreffen die Denkweise mehr als das Werkzeug.

7:08 Wer die Analyse überspringt und gleich Testcode erzeugen lässt, übernimmt ungeprüft die Annahmen der Implementierung — und testet dann genau das, was ohnehin gedacht war. Der zweite Punkt ist grundsätzlich: Fuzzing kann Fehler finden, nie Korrektheit beweisen. Ein grüner Lauf heißt „nichts gefunden", nicht „nichts da". Und der dritte ist praktisch: Verlassen Sie sich nicht auf den Gesprächsverlauf. Was im Prompt steht, hat Vorrang vor dem, was zehn Nachrichten vorher besprochen wurde.

Barrierefreiheit prüfen

7:37 Barrierefreiheit ist der Bereich, bei dem in vielen Teams am ehrlichsten gesagt wird: Wir wissen, dass wir müssten, aber uns fehlt das Wissen. Genau hier senkt KI die Einstiegshürde am deutlichsten — nicht, indem sie die Expertise ersetzt, sondern indem sie Befunde erklärt, nach Nutzerwirkung sortiert und offen benennt, was automatisiert gar nicht prüfbar ist.

7:57 Damit wird aus einem abstrakten Regelwerk eine abarbeitbare Liste. Barrierefreiheit heißt nicht, ein Häkchen zu setzen, sondern eine praktische Frage zu beantworten: Kommen alle Nutzer durch die zentralen Abläufe? Auch die, die nur mit der Tastatur arbeiten, einen Screenreader nutzen, die Seite stark vergrößern oder per Sprache steuern.

8:18 Der Maßstab dafür sind die Web Content Accessibility Guidelines — kurz WCAG — mit drei Stufen. Das Schöne daran: Es ist kein Bauchgefühl, sondern ein prüfbarer Katalog. Und ein guter Teil davon lässt sich automatisiert messen, wenn man weiß, welche Werkzeuge man ansetzt. Die Logik der drei Stufen ist eine Steigerung, und sie bauen aufeinander auf — das ist der Punkt, der am häufigsten übersehen wird.

8:42 Wer AA anstrebt, muss A vollständig miterfüllen; die Stufen sind keine Auswahlmenü-Optionen. In der Praxis ist AA der übliche Zielwert, und die Beispiele zeigen, warum: Ein verknüpftes Label und ein sichtbarer Tastaturfokus sind kein Luxus, sondern die Grundlage dafür, dass jemand ein Formular überhaupt bedienen kann. AAA mit seinem Kontrastverhältnis von sieben zu eins ist dagegen etwas, das man gezielt für einzelne Bereiche wählt, nicht pauschal.

9:09 Der Schlüssel steckt in Schritt zwei: die Zustände. Eine Seite ist nicht ein Zustand, sondern viele — mit ausgewähltem Element, mit leerem Suchergebnis, mit geöffnetem Panel. Wer das nicht sagt, bekommt eine Prüfung des Startzustands und hält sie für die Prüfung der Seite. Ebenso wichtig ist der letzte Schritt, und der ist erfrischend ehrlich: Fordern Sie eine Liste dessen, was automatisiert nicht prüfbar war. Screenreader-Tests etwa bleiben manuell.

9:35 Diese Liste ist kein Eingeständnis von Schwäche, sondern verhindert den gefährlichsten Irrtum — den grünen Bericht als Freibrief zu lesen. Nehmen Sie eine Seite aus Ihrem Projekt, idealerweise eine mit einem Formular. Die Fähigkeit, die Sie hier üben, ist das Bewerten: Ein Prüfwerkzeug liefert Befunde, aber es sagt Ihnen nicht, welcher davon einen Nutzer tatsächlich aussperrt.

9:58 Genau diese Einordnung nach Nutzerwirkung ist Ihre Aufgabe — mit der WCAG-Stufe als Anker. Und vergessen Sie den zweiten Teil des Erfolgskriteriums nicht: die offenen manuellen Prüfpunkte. Ein Bericht, der nicht sagt, was er nicht geprüft hat, ist gefährlicher als gar kein Bericht. Diese drei Punkte hängen zusammen. Ohne genannte Zustände prüfen Sie einen Bruchteil dessen, was Ihre Nutzer sehen.

10:22 Bei den Befunden kommt dann der gegenteilige Effekt: Eine einzige Ursache — etwa eine Farbdefinition im Stylesheet — erzeugt zwanzig Einzelmeldungen und lässt die Lage schlimmer aussehen, als sie ist. Deshalb gruppieren lassen. Und der dritte Punkt bleibt der wichtigste: Automatisierte Prüfung deckt nur einen Teil der Kriterien ab.

10:41 Ob ein Ablauf mit einem Screenreader wirklich verständlich ist, sagt Ihnen kein Werkzeug.

Lokalisierung unterstützen

10:47 Zum Abschluss dieses Moduls ein Bereich, den viele Teams auf „ist übersetzt, passt" verkürzen — und der genau deshalb so verlässlich Fehler produziert. Denn mit der Sprache ändern sich Zahlenformate, Textlängen, Schreibrichtungen und Erwartungen an Eingaben. Wir schauen uns an, wo die Risiken liegen, wie die KI sie sichtbar macht und wo ihre Einschätzung an eine Grenze stößt, die man kennen sollte.

11:10 Lokalisierung ist mehr als Übersetzung. Die Frage lautet nicht „ist der Text auf Deutsch?", sondern „funktioniert das Feature in dieser Sprache und Region noch?" Und da hängt einiges dran: Datums- und Zahlenformate, Dezimaltrenner, Einheiten, Textlängen, Validierungsmeldungen, Schreibrichtung. Ein Beispiel aus unserer Anwendung: Auf Englisch gibt jemand 1.5 Portionen ein, auf Deutsch erwartet man 1,5 mit Komma.

11:36 Wenn das Eingabefeld nur den Punkt akzeptiert, ist die App übersetzt — und trotzdem unbenutzbar. Genau solche Fälle sind gemeint. Der Nutzen liegt hier weniger im Testen als im Vorbereiten. Kaum ein Team hat Muttersprachler für jeden Zielmarkt — und genau diese Lücke kann die KI teilweise schließen. Sie leitet aus Release-Umfang und Anforderungen die Risikobereiche ab, schlägt je Sprache konkrete Prüfpunkte vor und erzeugt Testdaten in Schriftsystemen, die Sie selbst nicht tippen könnten.

12:05 Der vierte Punkt ist der heikelste und trotzdem wertvoll: eine erste Durchsicht der Übersetzungen auf Platzhalter, Tonfall und Textlänge. Als Vorprüfung ausgezeichnet, als Ersatz für eine sprachliche Freigabe nicht geeignet. Diese drei Sprachen stehen hier nicht zufällig — sie decken drei ganz verschiedene Problemklassen ab. Deutsch bringt Formatfragen und längere Labels, die Layouts sprengen.

12:28 Japanisch fordert die Textdarstellung und das Verhalten von Sucheingaben heraus. Und Arabisch dreht die gesamte Leserichtung um, was Feldreihenfolge, Ausrichtung und sogar Icons betrifft. Wenn eine Anwendung diese drei überlebt, ist sie für die meisten weiteren Sprachen gut aufgestellt. Nutzen Sie das Muster: Wählen Sie Testsprachen nicht nach Marktgröße, sondern nach der Art der Herausforderung.

12:52 Die Technik, um die es hier geht, ist elegant und schnell erklärt: Die Testschritte bleiben identisch, nur Eingabedaten und erwartete Texte wechseln je Sprache. Ein Test, viele Locales. Nehmen Sie einen bestehenden Test — gern den aus dem vorigen Modul — und bauen Sie ihn entsprechend um. Ihr Erfolgskriterium verlangt mindestens zwei Sprachen und ausdrücklich die formatabhängigen Eingaben.

13:15 Genau dort liegen nämlich die Fehler, die man sonst erst im Support-Ticket sieht: das Komma, das nicht akzeptiert wird. Der erste Punkt gilt eigentlich für das ganze Seminar, wird hier aber besonders oft verletzt: „Erstelle Lokalisierungstests für meine App" ist keine Aufgabe, sondern ein Wunsch. Geben Sie Sprachen, Seiten und Anforderungen mit.

13:36 Der zweite Punkt setzt eine ehrliche Grenze: Ob eine Formulierung in einer Sprache freundlich oder unpassend wirkt, kann ein Modell einschätzen — verantworten kann es das nicht. Und der dritte: Die aufgeworfenen Fragen brauchen einen Adressaten. Product Owner oder Sprachdienstleister — sonst bleibt eine gute Analyse ein Dokument ohne Wirkung.

13:57 Wenn Sie über die vier Kapitel hinwegschauen, sehen Sie immer dasselbe Muster. Gemessen wird mit deterministischen Werkzeugen — Lastgenerator, Fuzzer, Prüfbibliothek. Die KI erklärt, ordnet ein und priorisiert. Damit die Messung überhaupt etwas taugt, brauchen Sie explizite Grenzen im Prompt: Abbruchregeln, Zustände, Zielstufe.

14:17 Die Ergebnisse gehören maschinenlesbar abgelegt, nicht ins Terminal. Und was manuell bleibt, muss im Bericht stehen. Wer diese vier Punkte beherzigt, kann sich jeden weiteren nichtfunktionalen Bereich selbst erschließen — auch die, die wir hier nicht behandelt haben.

Nichtfunktionale Tests mit GenAI

14:34 Das ist die eigentliche Nachricht dieses Moduls: Bereiche, die bisher Spezialisten vorbehalten waren, werden für QA-Teams zugänglich. Nicht, weil die KI die Expertise ersetzt — sondern weil sie den Einstieg so weit senkt, dass man anfangen kann. Und der Wert liegt weniger im Erzeugen der Tests als im Deuten ihrer Ergebnisse.

14:53 Im nächsten Modul wechseln wir die Perspektive: vom Testen des Produkts zum Prüfen des Codes selbst — Code Review, statische Analyse, Review-Bots und die CI-Pipeline, die das alles zusammenhält.