KI im Softwaretest: wo Sprachmodelle beim Testen wirklich helfen

Warum das Testorakel die Grenze ist

Ein Test besteht aus zwei Teilen: der Eingabe und dem erwarteten Ergebnis. Der zweite Teil heißt in der Testlehre Testorakel und ist der Grund, warum Testerzeugung ein hartes Problem bleibt. Ein Sprachmodell kann Eingaben in großer Zahl erzeugen, aber es weiß nicht, was bei eurem Rabattsystem für einen Bestandskunden im dritten Jahr herauskommen soll. Es leitet das erwartete Ergebnis aus dem ab, was es sieht, und das ist meistens euer Code.

Daraus folgt die wichtigste Konsequenz für die Praxis: Erzeugte Tests, die aus dem Code abgeleitet wurden, sind Regressionsschutz und keine Fehlersuche. Sie stellen sicher, dass sich das Verhalten nicht unbemerkt ändert, und das ist ein echter Wert. Sie finden aber keinen Fehler, der schon vorher da war, denn sie halten ihn für das gewünschte Verhalten.

Der Umkehrschluss ist nützlich: Wenn ihr das erwartete Ergebnis aus der Anforderung nehmt und nicht aus dem Code, dann funktioniert die Arbeitsteilung. Das Modell liefert die Fälle, ihr liefert die Erwartung. Und wenn ihr für einen Fall keine Erwartung formulieren könnt, habt ihr einen Befund gefunden, der wertvoller ist als der Test selbst, nämlich eine unklare Anforderung.

Wo der Zeitgewinn tatsächlich anfällt

Der größte und unstrittigste Gewinn liegt bei Fehlermeldungen. Aus einer knappen Notiz, einem Screenshot und einem Protokollauszug wird eine Meldung mit Vorbedingungen, Schritten, erwartetem und beobachtetem Verhalten. Das ist genau die Fleißarbeit, die unter Zeitdruck als Erstes wegfällt und die der Entwicklung anschließend die meiste Zeit kostet. Die Prüfung dauert Sekunden, weil du weißt, was du gesehen hast.

Der zweite Bereich ist das Zusammenfassen. Ein Fehlerprotokoll mit zehntausend Zeilen, ein Bericht über einen fehlgeschlagenen Nachtlauf, eine Änderungsliste zwischen zwei Ständen: Daraus die relevanten Stellen zu ziehen, ist eine Aufgabe, bei der sich das Ergebnis unmittelbar am Original prüfen lässt. Für lange Dokumente lohnt sich ein Aufbau, bei dem das Modell auf eure eigenen Unterlagen zugreift, statt sie in die Anfrage zu kopieren.

Der dritte Bereich ist die Übersetzung zwischen Sprachwelten. Aus einer fachlichen Beschreibung eine Liste prüfbarer Abnahmekriterien machen, aus einem Testfall eine Beschreibung, die der Fachbereich versteht, aus einem Verhaltensmuster eine Formulierung in der Sprache eures Testrahmens. Diese Aufgaben sind gut definiert, das Ergebnis ist leicht zu beurteilen, und der Zeitgewinn ist über die Woche gerechnet erheblich.

Der vierte Bereich ist die Durchsicht bestehender Tests. Eine Suite auf Doppelungen prüfen, benannte Muster in der Struktur vorschlagen, unklare Testnamen umformulieren: Das sind Aufgaben, die niemand macht, weil sie sich nie lohnen, und die durch die Unterstützung erstmals in ein Zeitbudget passen.

Was ihr niemals ungeprüft übernehmt

Keine Zusicherung, die ihr nicht selbst begründen könnt. Ein erzeugter Test mit einem erwarteten Wert, den niemand nachgerechnet hat, ist schlimmer als kein Test, weil er Sicherheit vortäuscht. Wenn du im Review nicht sagen kannst, warum an dieser Stelle genau dieser Wert stehen muss, gehört die Zeile nicht in die Suite.

Keinen Bezeichner, der nicht existiert. Modelle erzeugen Methodennamen, Selektoren, Feldnamen und Konfigurationsschlüssel, die plausibel klingen und in eurem System nicht vorkommen. Im ausführbaren Code fällt das beim ersten Lauf auf. In einem Testfallkatalog, in einer Dokumentation oder in einer Fehlermeldung fällt es niemandem auf, bis jemand danach sucht.

Und keine Aussage über Abdeckung. Wenn ein Modell schreibt, dass eine Liste von Testfällen die Anforderung vollständig abdeckt, ist das eine Formulierung und keine Analyse. Vollständigkeit lässt sich nur gegen ein Modell der Anforderung prüfen, und dieses Modell müsst ihr aufstellen. Genau dafür gibt es die Verfahren des Testentwurfs, und genau deshalb ersetzt keine Unterstützung durch KI die Grundausbildung im Test.

Testdaten, Datenschutz und die Frage nach dem Werkzeug

Der attraktivste Anwendungsfall ist zugleich der heikelste. Realistische Testdaten sind in vielen Projekten der Engpass, und ein Modell erzeugt sie in Sekunden. Der Fehler entsteht dort, wo jemand einen Auszug aus dem Produktivbestand als Vorlage mitschickt. Damit werden personenbezogene Daten an einen Verarbeiter übermittelt, und ob das zulässig ist, hängt vom Vertrag, vom Verarbeitungsort und vom Zweck ab, nicht vom guten Willen.

Der saubere Weg ist die Beschreibung statt der Vorlage. Ihr formuliert die Struktur, die Formate, die Wertebereiche und die Sonderfälle, die euch wichtig sind, und lasst daraus Daten erzeugen. Das Ergebnis ist meistens sogar besser als ein anonymisierter Auszug, weil ihr die Randfälle gezielt anfordern könnt, statt zu hoffen, dass sie im Bestand vorkommen.

Zur Werkzeugfrage gehört eine schriftliche Festlegung, welches Angebot benutzt werden darf, wo es verarbeitet, ob Eingaben zum Training verwendet werden und ob es eine Betriebsvereinbarung braucht. Diese Klärung ist unbequem und einmalig. Ohne sie entsteht Schatten-IT, und die ist im Test besonders unangenehm, weil dort Daten aus allen Fachbereichen zusammenlaufen.

Zwei Themen, die regelmäßig verwechselt werden

Das eine ist der Einsatz generativer KI als Werkzeug in der eigenen Testarbeit, also alles, was auf dieser Seite steht. Das andere ist das Testen von Systemen, die selbst KI enthalten, und das ist eine ganz andere Aufgabe. Dort geht es um nicht deterministische Ausgaben, um die Bewertung von Modellgüte, um Verzerrungen in Trainingsdaten und um die Frage, wie man ein System abnimmt, das auf dieselbe Eingabe nicht immer dieselbe Antwort gibt.

Das ISTQB führt für beide Themen eigene Module. Für den Einsatz generativer KI in der Testarbeit gibt es Testing with Generative AI, das auf dem Foundation Level aufsetzt und Prompt-Techniken, Risiken wie Halluzination und Verzerrung sowie den Aufbau mit Zugriff auf eigene Unterlagen behandelt. Für das Prüfen von Systemen mit KI-Anteil gibt es ein separates Modul zum Testen von KI-Systemen. Wer das falsche bucht, ist danach für die andere Aufgabe nicht besser aufgestellt.

Für die Einordnung im Team hilft eine einfache Frage: Steht KI in eurem Produkt oder in eurem Werkzeugkasten? Wenn beides zutrifft, braucht ihr beides, aber nicht in derselben Person und nicht zur selben Zeit. Fangt mit dem an, was näher an eurem aktuellen Engpass liegt.