GenAI im Softwaretest

GenAI im Softwaretest

0:00 Künstliche Intelligenz verändert gerade jeden Teil der Softwareentwicklung — und die Qualitätssicherung macht da keine Ausnahme. Das ist keine ferne Zukunftsmusik: Testfälle entstehen heute in Minuten, Automatisierungsskripte schreiben sich fast von selbst, und ein Agent kann eine Anwendung im Browser erkunden, während wir zusehen.

0:19 In diesem Modul schauen wir uns an, was das konkret für die tägliche QA-Arbeit bedeutet. Und wir schauen genauso genau auf die andere Seite: Wo führt uns diese Technik in die Irre? Denn beides gehört zusammen — die Beschleunigung und das Misstrauen, das sie nötig macht.

Wie GenAI die QA verändert

0:35 Bevor wir über Werkzeuge reden, lohnt sich ein Blick auf die Arbeit selbst. Was tun QA-Engineers eigentlich den ganzen Tag, wo geht die Zeit hin — und an welchen Stellen setzt generative KI wirklich an? Wir schauen uns dafür zuerst an, was Qualitätssicherung alles umfasst, dann, welche Teile davon besonders teuer sind, und schließlich, wo im Entwicklungszyklus die Unterstützung ansetzt.

0:57 Am Ende dieses Kapitels haben Sie eine Landkarte, auf der Sie Ihre eigene Arbeit wiederfinden. Qualitätssicherung ist deutlich mehr als Tests klicken. Sie beginnt bei der Frage, wie im Projekt überhaupt getestet wird, geht über das Entwerfen von Testfällen und deren Ausführung bis zu Fehlermeldungen, Reviews und Prozessverbesserung.

1:16 Stellen Sie sich das wie die Bauaufsicht auf einer Baustelle vor: Da wird nicht nur am Ende geprüft, ob das Haus steht, sondern laufend, ob nach Plan gebaut wird. Und genau weil QA so viele verschiedene Tätigkeiten umfasst, greift generative KI an so vielen Stellen ein — nicht an einer einzigen, sondern quer durch die gesamte Kette.

1:35 Der eigentliche Kostentreiber in der QA ist selten der einzelne Testlauf. Teuer wird die Pflege: Testfälle wollen aktuell gehalten werden, Edge Cases findet nur, wer die Domäne kennt, und Testautomatisierung verlangt echte Programmierfähigkeiten plus eine Anfangsinvestition, die sich erst nach Monaten rechnet. Dazu kommt der ganze Verwaltungsanteil: Fehler melden, triagieren, Berichte schreiben, Testpläne abstimmen. Nichts davon ist unwichtig, aber vieles davon ist mechanisch.

2:03 Und genau mechanische, wiederkehrende Arbeit ist der Bereich, in dem generative KI ihre Stärken ausspielt — nicht beim Urteil, sondern beim Vorbereiten des Urteils. Die Logik hinter dieser Übersicht ist wichtiger als die einzelnen Zeilen: KI setzt nicht an einer Stelle an, sondern begleitet den gesamten Zyklus. Und je früher sie einsteigt, desto größer der Hebel.

2:25 Wer erst beim Testlauf Hilfe holt, verschenkt den größten Teil des Nutzens — denn Ambiguitäten in den Anforderungen kosten später ein Vielfaches. Der zweite Gedanke: In jeder Phase liefert die KI Zuarbeit, keine Entscheidung. Sie schlägt Regressionskandidaten vor, sie wählt sie nicht aus. Behalten Sie dieses Muster im Kopf — es zieht sich durch das gesamte Seminar.

2:47 Der entscheidende Punkt bei diesem Ablauf ist nicht die Reihenfolge, sondern die Haltung dahinter. Wir übergeben Kontext, wir bekommen einen Entwurf — und dann beginnt die eigentliche Arbeit: prüfen, was ist Annahme und was ist belegt. Anfänger neigen dazu, bei einem schlechten Ergebnis den Prompt komplett neu zu schreiben und noch einmal zu würfeln.

3:07 Deutlich wirksamer ist es, gezielt nachzuschärfen: „Diese drei Fälle sind Dubletten, fasse sie zusammen." Und am Ende steht immer der Abgleich mit der laufenden Anwendung. Denn was das Modell beschreibt, muss nicht dem entsprechen, was Ihre Software tatsächlich tut. Jetzt sind Sie dran. Nehmen Sie eine User Story aus Ihrem eigenen Projekt — je realer, desto lehrreicher.

3:29 Es geht ausdrücklich nicht darum, möglichst viele Testfälle zu erzeugen; das schafft das Modell mühelos allein. Die Fähigkeit, die Sie hier üben, ist das fachliche Bewerten: Welche Fälle sind wirklich unterschiedlich, welche sind derselbe Gedanke in anderen Worten? Ihr Ziel ist ein reduzierter Satz, bei dem Sie für jedes Akzeptanzkriterium den zugehörigen Testfall zeigen können.

3:52 Wenn Sie schneller fertig sind, lassen Sie sich zusätzlich eine Coverage-Matrix erzeugen. Diese drei Fallen begegnen einem fast immer beim ersten Versuch. Die erste entsteht aus Höflichkeit gegenüber dem Modell: Wir geben zu wenig Kontext, und prompt erfindet es Features, die es in unserer Anwendung gar nicht gibt. Die zweite ist tückischer — eine lange, sauber formatierte Liste wirkt vollständig, ist es aber selten.

4:17 Vollständigkeit lässt sich nur gegen die Akzeptanzkriterien prüfen, nicht am Umfang ablesen. Und die dritte ist eine Kostenfalle mit Zeitverzögerung: Was heute großzügig erzeugt wurde, will morgen gepflegt werden. Gruppieren Sie, bevor Sie übernehmen.

Qualität in KI-gestützten Tests sichern

4:33 Bis hierhin klang das alles ziemlich verlockend. Jetzt drehen wir die Perspektive: Was passiert, wenn die KI überzeugend klingt und trotzdem falsch liegt? Genau diese Frage entscheidet darüber, ob KI in Ihrer QA ein Gewinn oder ein Risiko wird. Wir sehen uns die typischen Fehlerbilder an, verstehen, warum sie technisch unvermeidbar sind — und leiten daraus ganz praktische Arbeitsregeln ab.

4:56 Denn Misstrauen allein hilft niemandem; es braucht ein Verfahren. Halluzination ist ein hübsches Wort für ein unangenehmes Phänomen: Das Modell liefert eine Antwort, die klingt, als sei sie geprüft — und sie ist frei erfunden. Ein Beispiel aus der Praxis: Aus einem DOM-Auszug entsteht ein sauber strukturiertes Page Object, mit guten Namen, ordentlich sortiert.

5:17 Nur existieren die verwendeten Attribute in der Seite gar nicht. Der Test scheitert sofort, und die Fehlersuche beginnt an der falschen Stelle — nämlich im eigenen Code. Das ist das häufigste Risiko KI-gestützter Testarbeit, und es ist besonders heimtückisch, weil das Ergebnis auf den ersten Blick professionell aussieht.

5:37 Diese vier Risiken haben eine gemeinsame Wurzel: Das Modell versteht Ihr System nicht, es sagt Muster vorher. Deshalb erfindet es Selektoren, wenn ihm welche fehlen. Deshalb bekommen Sie bei zwei identischen Anfragen zwei verschiedene Abdeckungen — was gefährlich wird, wenn Sie die erste Antwort für vollständig halten. Deshalb empfiehlt es ein Werkzeug, ohne nach Teamerfahrung, Budget oder Technologiestack zu fragen. Und deshalb sagt es nie „ich bin mir unsicher".

6:05 Menschen signalisieren Zweifel, Modelle nicht. Dieses fehlende Zögern ist kein Detail — es ist der Grund, warum Gegenprüfen zur Pflicht wird. Das Prinzip hinter dieser Aufstellung: Das Risiko steigt genau dort, wo dem Modell der Kontext fehlt, den es nie hatte. In komplexen Systemen wirken Fehler indirekt — was hier harmlos aussieht, kippt drei Abhängigkeiten weiter.

6:27 In Fachdomänen wie Medizin oder Finanzen steckt entscheidendes Regelwissen in Vorschriften, nicht in Trainingsdaten. Und wo ein Ausfall unmittelbare reale Folgen hat, ist ein plausibel klingender Irrtum teurer als gar keine Antwort. Die Konsequenz ist keine Verbotsliste, sondern eine Skala: Je höher der Einsatz, desto engmaschiger die menschliche Prüfung.

6:49 Worauf es bei diesem Prompt ankommt, sind nicht die Formulierungen, sondern drei Bewegungen. Erstens: eine Rolle setzen, damit Tonfall und Detailtiefe stimmen. Zweitens: die Quellen einzäunen — nur diese Story, nur dieser DOM-Auszug, sonst nichts. Drittens, und das ist der eigentliche Trick: dem Modell einen legitimen Ausweg anbieten.

7:11 Wer nur „erfinde nichts" schreibt, lässt offen, was das Modell mit einer Lücke tun soll — also füllt es sie. Wer sagt „markiere Lücken als offen", bekommt die Lücke als Ergebnis geliefert. Ein Verbot allein wirkt schwächer als ein Verbot mit Alternative. Der rote Faden dieser fünf Schritte lautet: Der Output ist Rohmaterial, nicht Ergebnis.

7:33 Wer ihn als Entwurf behandelt, prüft automatisch anders — kritischer, und gegen die richtige Referenz, nämlich die laufende Anwendung. Die Punkte drei und vier gehören eng zusammen: Je präziser Sie Kontext und Randbedingungen vorgeben, desto weniger müssen Sie hinterher hinterfragen. Und der letzte Schritt ist der wichtigste, auch wenn er unspektakulär klingt.

7:54 Was getestet wird, mit welcher Tiefe und mit welchem Risiko — das bleibt eine Entscheidung, die Menschen verantworten. Die KI liefert die Grundlage dafür. In dieser Übung drehen wir den Spieß um: Sie erzeugen nicht, Sie prüfen. Nehmen Sie einen generierten Testfallsatz — gern den aus der vorigen Aufgabe — und gehen Sie ihn Zeile für Zeile durch mit einer einzigen Frage: Wodurch ist das gedeckt?

8:18 Durch eine Anforderung, durch die Anwendung, oder durch nichts? Genau die dritte Kategorie ist Ihr Ergebnis. Diese Übung wirkt mühsam, und sie ist es auch. Aber sie schult den Blick, den Sie danach automatisch mitbringen — und der unterscheidet einen produktiven KI-Einsatz von einem gefährlichen. Diese drei Muster erkennen Sie im Alltag schnell wieder.

8:39 Das „Du hast recht" ist das bekannteste: Man weist auf einen Fehler hin, bekommt sofort Zustimmung — und eine neue Antwort, die genauso selbstsicher daneben liegen kann. Zustimmung ist keine Analyse. Der zweite Punkt trifft alle, die einmal generieren und weiterarbeiten: Zwei Läufe desselben Prompts decken unterschiedliche Szenarien ab.

8:59 Wer das nicht weiß, hält die erste Antwort für die vollständige. Und der dritte ist der subtilste: Wir Menschen lesen selbstsichere Formulierung unwillkürlich als Verlässlichkeit. Das ist bei Modellen schlicht kein gültiger Indikator. Wenn man diese vier Punkte zusammennimmt, ergibt sich ein klares Bild der neuen Rolle. Testen war nie nur Tests schreiben — es war immer auch Risiko einschätzen: Was kann schiefgehen, was ist in diesem System schon einmal gescheitert, was tut den Nutzern am meisten weh?

9:29 Genau dieser Teil lässt sich nicht auslagern, weil er Kontext braucht, den nur das Team hat. Was sich verschiebt, ist der Schwerpunkt: weg vom Erstellen, hin zum Steuern und Validieren. Das ist keine Abwertung des Berufs — es ist eine Aufwertung des Urteils.

GenAI im Softwaretest

9:44 Halten wir fest: Generative KI nimmt der QA vor allem die repetitive Arbeit ab — und das spürbar. Was sie nicht abnimmt, ist die Verantwortung für das Ergebnis. Der Rollenschwerpunkt verschiebt sich vom Machen zum Prüfen und Steuern, und wer diesen Wechsel bewusst vollzieht, gewinnt am meisten. Im nächsten Modul werden wir das ganz konkret: Wir lassen uns eine Teststrategie erzeugen, sehen, wo sie gut wird, wo sie generisch bleibt — und wie viel Produktkontext es braucht, damit etwas Brauchbares dabei herauskommt.