Der Satz fällt meistens im Sprint-Review: Wir sollten das mit der KI mal ausprobieren. Zwei Wochen später liegen zweihundert erzeugte Testfälle im Werkzeug. Sie sind sauber formuliert, sie sehen richtig aus, und niemand im Team kann sagen, welche davon etwas taugen.
Wer die Freigabe unterschreibt, steht dann vor einer Frage, die vorher niemand gestellt hat: Woher kommt das eigentlich? Dieser Beitrag beantwortet sie für QET AI, und zwar bevor Sie in dieser Lage sind.
22 Jahre lang war ich der, der prüft. Erst als Tester, dann als Testmanager, heute als Unternehmer mit einer eigenen Testberatung. Seit einigen Wochen baue ich an QET AI, einer Appliance, die Testfälle erzeugt und im eigenen Netz des Kunden läuft. Damit sitze ich zum ersten Mal auf der anderen Seite des Tisches: Ich prüfe, was meine eigene Maschine vorschlägt.
Unter einem Beitrag über den EU AI Act stellte mir ein Leser diese Woche die Frage, auf die es ankommt: Auf welcher Basis erzeugt Dein Werkzeug die Tests?
Das ist die richtige Frage, und sie wird zu selten gestellt. Die meisten Vorführungen von KI-Testwerkzeugen zeigen den beeindruckenden Teil, also den fertigen Testfall nach wenigen Sekunden. Woher der Vorschlag stammt, bleibt offen. Dieser Beitrag beantwortet genau das für QET AI.
Warum die Herkunft eines KI-Testfalls mehr zählt als der Testfall selbst
Der ISTQB-Lehrplan zum Testen KI-basierter Systeme hat einen eigenen Abschnitt zum Automation Bias. Menschen übernehmen Vorschläge von Systemen zu bereitwillig. Der Lehrplan beziffert die Folge: Die Qualität der Entscheidungen sinkt typischerweise um fünf Prozent, je nach Kontext deutlich mehr.
Ein Testfall, der gut formuliert aussieht, wird also eher durchgewinkt als einer, der holprig klingt. Wie gut ein Satz klingt, sagt aber nichts darüber, ob er fachlich stimmt. Wer prüfen soll, muss wissen, worauf er schaut. Ein Werkzeug, das seine Quellen nicht offenlegt, liefert eine geschlossene Kiste, und eine geschlossene Kiste kann man nicht prüfen, nur glauben.
Deshalb hat in QET AI jeder erzeugte Testfall eine ausgewiesene Herkunft. Es gibt genau drei Quellen.
Inhaltsverzeichnis
- Warum die Herkunft eines KI-Testfalls mehr zählt als der Testfall selbst
- Für wen sich das lohnt, und für wen nicht
- Testfälle aus Anforderungen ableiten: was die Spezifikation hergibt
- Wenn die Spezifikation schweigt: Testfälle aus der laufenden Anwendung
- Was das Team schon freigegeben hat: Testfälle aus dem eigenen Bestand
- Prüfbar bleiben: Freigabe, Protokoll und Nachweis
- Was KI beim Testen nicht kann
- Wie die Testfälle in Ihr Testmanagement kommen
- Warum die Modelle im eigenen Netz rechnen
- Drei Einwände, die im Gespräch immer kommen
- Der Pilot: acht bis zwölf Wochen im eigenen Netz
- Häufige Fragen zu KI-erzeugten Testfällen
Für wen sich das lohnt, und für wen nicht
Der Ansatz lohnt sich nicht überall gleich. Er lohnt sich dort, wo zwei Dinge zusammenkommen: viele Testfälle und die Pflicht, ihre Entstehung zu belegen.
Drei Rollen
Freitag ist Freeze. Die Regression umfasst vierhundert Fälle, und der Fachbereich hat am Mittwoch drei Anforderungen nachgeschoben. Sie brauchen jetzt keine Diskussion über künstliche Intelligenz, Sie brauchen die vierzig Testfälle, die zu diesen drei Anforderungen gehören. Die Generierung nimmt Ihnen das Schreiben ab. Was sie Ihnen nicht abnimmt, ist die Entscheidung, welche vierzig es sind. Genau dafür gewinnen Sie Zeit.
Die Revision hat einen Termin angekündigt. Man wird Sie fragen, wie die Testfälle entstanden sind, die Ihre Freigabe tragen. Für Sie zählt weniger, wie schnell ein Testfall entsteht, als ob Sie in achtzehn Monaten noch erklären können, warum er so aussieht. Herkunftsvermerk, Protokoll und Prüfsummenkette sind für diesen Termin gebaut, nicht für die Vorführung.
Ihre Anforderungen sind besser, als alle behaupten. Sie merken es daran, wo die Generierung ins Straucheln kommt: Ein Vorschlag mit niedrigem Vertrauenswert ist kein Fehler des Werkzeugs, sondern der Finger auf einer Fachregel, über die zwei Abteilungen unterschiedlicher Meinung sind. Das ist unangenehm und billiger als derselbe Streit nach der Abnahme.
Dazu kommt eine vierte Gruppe, die in Projekten oft zu spät gefragt wird: Revision, Compliance und Datenschutz. Wer diese Stellen erst nach der Werkzeugauswahl einbindet, verhandelt zweimal.
Besonders in stark reguliertem Umfeld
Je strenger die Nachweispflicht, desto größer der Unterschied zwischen einem Werkzeug, das Testfälle erzeugt, und einem, das ihre Entstehung dokumentiert.
Finanzdienstleister und Versicherer. DORA ist seit dem 17. Januar 2025 verbindlich anzuwenden und verlangt ein dokumentiertes Rahmenwerk für IKT-Risiken, einschließlich der eingesetzten Werkzeuge und der Steuerung von Drittanbietern. Ein Generator, dessen Vorschläge sich nicht zurückverfolgen lassen, hinterlässt genau dort eine Lücke.
Öffentliche Verwaltung und öffentliche IT-Dienstleister. Fachverfahren enthalten Daten, die das Haus nicht verlassen dürfen. Ein Werkzeug, das Anforderungen an eine externe Schnittstelle schickt, scheidet aus, unabhängig davon, wie gut es generiert.
Gesundheitswesen und Medizinprodukte. Wo die Softwarezulassung an einer dokumentierten Verifikation hängt, ist die Frage nach der Quelle eines Testfalls Teil der Akte, nicht Teil des Werkzeugvergleichs.
Energie, Verkehr und weitere Betreiber kritischer Anlagen. Hier kommt die Verfügbarkeitsanforderung dazu. Ein brüchiger Test, der bei jedem Umbau der Oberfläche neu geschrieben wird, kostet mehr, als er absichert.
Quer über alle diese Branchen liegt seit dem 2. August 2026 der EU AI Act. Wenn KI an der Entstehung Ihrer Testfälle beteiligt ist, gehört das dokumentiert. Wer das erst nach der Einführung nachzieht, dokumentiert rückwärts, und rückwärts dokumentieren ist teuer.
Und wer bereits generiert
Wenn in Ihrem Haus schon ein Werkzeug Testfälle erzeugt, gleich welches, stellt sich die Frage nach der Herkunft trotzdem. Hunderte plausibel aussehende Szenarien sind kein Zugewinn an Sicherheit, solange niemand sagen kann, welche davon im Ernstfall etwas entdecken. Diese Frage hängt nicht daran, wer die Testfälle geschrieben hat.
Wann sich der Aufwand nicht lohnt
Wenn Sie ein kleines Team ohne externe Nachweispflicht sind, wenn Ihre Anwendung sich wöchentlich grundlegend ändert, oder wenn Ihre Anforderungen ausschließlich im Kopf einzelner Personen existieren, dann ist die Generierung der falsche erste Schritt. Dann fehlt zuerst die Quelle, aus der sich überhaupt etwas ableiten lässt.
Testfälle aus Anforderungen ableiten: was die Spezifikation hergibt
Anforderungen, Akzeptanzkriterien und Fachregeln sind die Primärquelle. Sie beschreiben, was die Software tun soll, und sind damit das Einzige, woran sich ein erwartetes Ergebnis überhaupt festmachen lässt.
Der Generator leitet daraus strukturierte Testfälle ab: Vorbedingung, Schritte, erwartetes Ergebnis. Er schlägt zusätzlich Negativfälle vor, also die ungültigen Äquivalenzklassen, die im Anforderungstext meist fehlen. Ein Beispiel aus einer anonymisierten Vertragsverwaltung:
TC-ACME-118 Storno mit Rückabwicklung Folgesoll, Confidence 94, Herkunft REQ-441
Angenommen ein aktiver Vertrag mit gebuchtem Folgesoll, wenn der Vertrag zum Stichtag storniert wird, dann wird das Folgesoll anteilig zurückgerechnet.
Vorgeschlagener Negativfall: Ein Storno nach Ablaufdatum muss abgewiesen werden.
Merken Sie sich diesen Storno-Fall. Er begleitet uns durch den ganzen Beitrag, und an jeder Station zeigt sich eine andere Seite davon.
Die Grenze dieser Quelle ist die alte: Anforderungen sind selten präzise. Und anders als ein Mensch fragt die KI nicht nach. Bei einer Lücke trifft sie stillschweigend eine Annahme und erzeugt schnell das Falsche. Genau deshalb gibt es die beiden anderen Quellen, und genau deshalb steht am Ende immer eine menschliche Freigabe.
Wenn die Spezifikation schweigt: Testfälle aus der laufenden Anwendung
Wenn die Vorgaben dünn sind, kann ein Agent die Anwendung erkunden. Er bekommt eine Adresse oder eine registrierte Anwendung, öffnet sie in einem Browser und liest, was tatsächlich da ist: Formulare, Schaltflächen, Rollen aus der Barrierefreiheits-Struktur, Navigationswege. Daraus schlägt er Abläufe vor, und aus einem bestätigten Ablauf entsteht der Testfallentwurf.
Ein Beispiel, das ich selbst gefahren habe: Der Erkundungslauf gegen unsere eigene Website fand das Suchformular und über hundert Navigationsziele. Daraus entstand ein erster Testfall, der anschließend lesend gegen die laufende Seite geprüft wurde, vier von vier Schritten bestanden.
Diese Quelle hat eine Eigenschaft, die man verstehen muss: Sie beschreibt, was die Anwendung tut, nicht was sie tun sollte. Ein bestehender Fehler würde auf diesem Weg zum Testfall geadelt und damit zementiert. Erkundung ersetzt die Spezifikation also nicht, sie ergänzt sie. Deshalb startet dieser Weg mit einem niedrigeren Vertrauenswert, und deshalb ist die Herkunft am Testfall vermerkt, damit der Prüfer weiß, dass hier die Anwendung selbst die Vorlage war.
Wie autonome Agenten dabei technisch vorgehen, beschreiben wir ausführlicher auf unserer Seite zu Agentic AI Testing.
Was das Team schon freigegeben hat: Testfälle aus dem eigenen Bestand
Jeder Testfall, den ein Mensch freigegeben hat, wandert in ein Musterbuch. Bei der nächsten Generierung sucht das System darin nach ähnlichen Fällen und nutzt sie als Referenz. Über die Zeit lernt QET AI so den Stil, die Tiefe und die fachlichen Muster des jeweiligen Hauses.
Der entscheidende Punkt daran: Der Bestand wächst nur um das, was vorher durch die Freigabe kam. Das System lernt aus geprüfter Arbeit, nicht aus sich selbst. Die Freigabe ist damit nicht nur ein Tor, sondern auch der Filter, der bestimmt, was überhaupt Vorbild werden darf.
Fehlt ein passendes Muster, sagt das System das. Derselbe Vertrag, ein anderer Fall:
TC-ACME-119 Wiederinkraftsetzung nach Mahnstopp, Confidence 72
Hinweis des Systems: Confidence unter 80, die Fachregel zum Mahnstopp ist im Musterbuch nicht eindeutig hinterlegt, Review empfohlen.
Der zugehörige Testcode nutzt Bedienelemente so, wie ein Anwender sie wahrnimmt, also Rolle und Beschriftung statt technischer Selektoren, und liegt hinter einem Seitenobjekt:
test('Wiederinkraftsetzung nach Mahnstopp', async ({ page }) => {
const vertrag = new VertragPom(page);
await vertrag.oeffnen('P-100482');
await page.getByRole('button', { name: 'Wiederinkraftsetzen' }).click();
await expect(page.getByText('Status: aktiv')).toBeVisible();
await expect(vertrag.mahnstoppBadge).toBeHidden();
});
Das ist kein Schönheitsthema. Tests, die an CSS-Klassen hängen, brechen beim nächsten Umbau der Oberfläche, und ein brüchiger Test kostet mehr, als er absichert.
Prüfbar bleiben: Freigabe, Protokoll und Nachweis
Erzeugen ist der einfache Teil. Prüfbar bleiben ist der schwierige.
Jeder Vorschlag bekommt einen Vertrauenswert und läuft durch ein Freigabe-Gate nach ISTQB-Kriterien, bevor ihn ein Mensch überhaupt zu sehen bekommt. Das ersetzt kein Review, es sortiert vor.
Der Mahnstopp-Fall von eben ist genau so einer. Er kommt mit Vertrauenswert 72 an das Gate, wird nicht durchgewinkt, sondern vorgelegt, und ein Mensch entscheidet über ihn. Das ist der Moment, auf den es ankommt.
Jede Freigabe landet in einem Protokoll: wer, wann, aus welcher Quelle, mit welchem Modell und mit welcher Version des verwendeten Prompts. Die Einträge sind über eine Prüfsummenkette verbunden. Wird ein Eintrag nachträglich geändert, fällt das bei der Prüfung der Kette auf. Ein Protokoll, das sich still korrigieren lässt, ist im Audit wertlos.
Dazu kommt Reproduzierbarkeit. Die Modelle laufen mit Temperatur null und festem Startwert, dieselbe Eingabe ergibt denselben Vorschlag. Ohne diese Eigenschaft wäre die Protokollierung eine Fassade, denn niemand könnte einen Vorschlag später nachstellen.
Für die Arbeit selbst ist nicht ein einziges Modell zuständig, sondern mehrere spezialisierte: eines für die fachliche Ableitung, eines für die Codeerzeugung, eines für die Ähnlichkeitssuche im Musterbuch. Jedes davon ist austauschbar, wer eigene Modelle betreibt, kann sie einsetzen.
Was KI beim Testen nicht kann
Es entscheidet nicht, welche Risiken zählen.
Vollständiges Testen ist nicht möglich, das ist einer der Grundsätze des Testens und war schon vor der KI wahr. Also muss jemand auswählen, welche Szenarien wichtig sind und welche man bewusst weglässt. Diese Auswahl ist Teststrategie, sie beruht auf Erfahrung mit dem Fachbereich und dem Schadenspotenzial, und sie bleibt beim Menschen. Ein Freigabe-Gate filtert, was erzeugt wurde. Über das, was hätte erzeugt werden müssen, sagt es nichts.
Ebenso wenig prüft sich so ein System selbst. Das ISTQB-Glossar nennt die Informationsquelle für das erwartete Ergebnis Testorakel, und ein Pseudo-Orakel muss unabhängig abgeleitet sein. Ein Modell, das seinen eigenen Vorschlag bewertet, prüft gegen denselben Kontext, aus dem es ihn erzeugt hat. Auch ein zweites Modell auf ähnlichen Trainingsdaten löst das nicht. Die unabhängige Referenz kommt aus Anforderungen, Akzeptanzkriterien und Reviews, also von Menschen.
Und der Vertrauenswert ist kein Nachweis. Er ist die Selbsteinschätzung des Modells im Moment der Erzeugung, keine Messung am fertigen Test. Ein Vorschlag mit hohem Wert kann fachlich danebenliegen, ein Vorschlag mit niedrigem Wert kann richtig sein. Der Wert steht deshalb am Testfall, nicht an seiner Stelle.
Schneller erzeugen heißt nicht besser auswählen. Der Engpass wandert vom Schreiben zum Priorisieren.
Wie die Testfälle in Ihr Testmanagement kommen
Ein erzeugter Testfall, der in einem geschlossenen Werkzeug liegt, hilft niemandem. Die Frage nach der Anbindung kommt in jedem Gespräch direkt nach der Frage nach dem Datenschutz.
Die Ergebnisse liegen in offenen Formaten vor: Testfälle als Markdown mit strukturiertem Vorspann, dieselben Testfälle als Excel-Arbeitsmappe für den Fachbereich, ausführbarer Code für Playwright oder Cypress, und Ausführungsergebnisse als JUnit XML. JUnit XML ist der Standardweg in praktisch jedes Testmanagement-Werkzeug und in jede Bauumgebung, von Jenkins über GitLab bis Azure Pipelines.
Der Abgleich läuft in beide Richtungen. Ändert der Fachbereich einen Testfall in der Excel-Mappe, gewinnt bei einem Konflikt standardmäßig die Kundenseite. Das ist eine bewusste Entscheidung: Das Werkzeug schreibt Ihre Fachlichkeit nicht um.
Die Bezeichner folgen der Struktur, die Testmanagement-Werkzeuge ohnehin kennen: Testfall, Testsammlung, Testplan, Testdurchführung. Ein Import muss die Hierarchie also nicht erst nachbauen.
Warum die Modelle im eigenen Netz rechnen
Seit dem 2. August 2026 gilt Artikel 50 des EU AI Act. Menschen müssen erkennen können, wenn sie mit einer KI sprechen, und KI-erzeugte Inhalte müssen maschinenlesbar gekennzeichnet sein. Die Fristen für Hochrisiko-Systeme sind auf Dezember 2027 verschoben worden, diese nicht. Was der EU AI Act darüber hinaus an Qualitätsnachweisen verlangt, haben wir im Beitrag EU AI Act: Qualitätssicherung für KI-Systeme aufgeschrieben. In der Finanzbranche kommt DORA hinzu, mit eigenen Anforderungen an die Steuerung und Dokumentation von IKT-Risiken.
Denken Sie den Storno-Fall zu Ende. Er enthält Vertragsnummern, Fristen und die Fachregel zur Rückabwicklung. Genau diese Angaben würden das Haus verlassen, wenn die Generierung an einer externen Schnittstelle hinge.
Dazu kommt der praktische Grund. Anforderungen, Fachregeln und Testdaten gehören zum Kern eines Unternehmens. Wer sie an eine externe Schnittstelle schickt, muss das begründen können. Deshalb rechnen die Modelle von QET AI im Netz des Kunden, und deshalb bleiben die erzeugten Tests in offenen Formaten, die sich jederzeit exportieren lassen. Die Tests gehören dem, der sie verantwortet.
Drei Einwände, die im Gespräch immer kommen
„Das macht unser Werkzeug auch schon." Möglich. Die Frage ist nicht, ob es erzeugt, sondern was am Testfall steht, wenn jemand in zwei Jahren fragt, woher er stammt.
„Unsere Anforderungen sind zu schlecht dafür." Dann läuft ein rein dokumentgetriebenes Werkzeug leer. Deshalb gibt es die Erkundung an der laufenden Anwendung als zweiten Einstieg.
„Wir haben doch schon eine Testsuite." Gut. Wissen Sie, wie viele Ihrer Tests einen Fehler finden würden, wenn einer da wäre? Das ist eine andere Frage als die nach der Abdeckung, und sie wird selten gestellt.
Der Pilot: acht bis zwölf Wochen im eigenen Netz
Wenn Sie in einer regulierten Branche testen und Ihre Testautomatisierung mit KI absichern wollen, ohne die Hoheit über Daten und Tests abzugeben, dann lassen Sie uns über einen abgegrenzten Piloten sprechen. Acht bis zwölf Wochen, ein Anwendungsfall von Ihnen, ein bis zwei Ansprechpartner mit etwa einem halben Tag pro Woche. Am Ende steht eine von Ihrem Team freigegebene Testautomatisierung in Ihrem Netz und die vollständige Nachweiskette dazu.
Häufige Fragen zu KI-erzeugten Testfällen
Woher nimmt QET AI die Testfälle?
Aus genau drei Quellen: aus der Spezifikation, also Anforderungen, Akzeptanzkriterien und Fachregeln, aus der Erkundung der laufenden Anwendung, und aus den bereits freigegebenen Testfällen des Hauses. Jeder Vorschlag trägt seine Quelle als Vermerk und einen Vertrauenswert.
Verlassen unsere Anforderungen und Testdaten das Unternehmen?
Nein. Die Modelle rechnen im Netz des Kunden. Anforderungen, Fachregeln und Testdaten werden an keine externe Schnittstelle geschickt. Die erzeugten Tests bleiben in offenen Formaten und lassen sich jederzeit exportieren.
Ersetzt die KI das Testreview?
Nein. Vor dem Menschen liegt ein Freigabe-Gate mit Prüfkriterien nach ISTQB, das sortiert vor. Die Freigabe selbst verantwortet immer eine Person. Der ISTQB-Lehrplan zum Testen KI-basierter Systeme beziffert den Automation Bias, also die Neigung, Vorschläge zu bereitwillig zu übernehmen, mit einem typischen Qualitätsverlust von rund fünf Prozent.
Wie lässt sich ein einzelner Testfall später nachweisen?
Jede Freigabe landet in einem Protokoll: wer, wann, aus welcher Quelle, mit welchem Modell und mit welcher Version des verwendeten Prompts. Die Einträge sind über eine Prüfsummenkette verbunden, nachträgliche Änderungen fallen bei der Prüfung auf. Weil die Modelle mit Temperatur null und festem Startwert rechnen, ergibt dieselbe Eingabe denselben Vorschlag.
Woher weiß ich, dass ein erzeugter Testfall überhaupt Fehler findet?
Das ist die wichtigste Frage, und sie ist nicht dieselbe wie die nach dem Vertrauenswert. Der Vertrauenswert ist die Selbsteinschätzung des Modells im Moment der Erzeugung. Er sagt nichts darüber, ob der Testfall einen Defekt entdeckt, wenn einer da ist. Diese Prüfung leistet heute das Review durch einen Menschen, der die Fachlichkeit kennt. Wer ein Werkzeug bewertet, sollte auf dieser Unterscheidung bestehen, auch bei anderen Anbietern.
Was kann das Werkzeug nicht?
Es entscheidet nicht, welche Risiken zählen. Vollständiges Testen ist nicht möglich, also muss jemand auswählen, welche Szenarien wichtig sind. Diese Auswahl ist Teststrategie und bleibt beim Menschen. Ebenso wenig prüft sich das System selbst: Ein Modell, das seinen eigenen Vorschlag bewertet, prüft gegen denselben Kontext, aus dem es ihn erzeugt hat.
Wie fängt man an?
Mit einem abgegrenzten Piloten: acht bis zwölf Wochen, ein Anwendungsfall aus Ihrem Haus, ein bis zwei Ansprechpartner mit etwa einem halben Tag pro Woche. Am Ende steht eine von Ihrem Team freigegebene Testautomatisierung in Ihrem Netz einschließlich der Nachweiskette.