Auf welcher Basis eine KI Testfälle schreibt

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 wichtiger ist als das Ergebnis

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.

Quelle 1: die Spezifikation

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.

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.

Quelle 2: die Anwendung selbst

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.

Quelle 3: die bereits freigegebenen Testfälle

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. Aus derselben Vertragsverwaltung:

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.

Was nach der Generierung passiert

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.

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 das Werkzeug 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.

Schneller erzeugen heißt nicht besser auswählen. Der Engpass wandert vom Schreiben zum Priorisieren.

Warum das Ganze im eigenen Netz läuft

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.

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.

Warum das für mich ein Meilenstein ist

Dieser Beitrag ist für mich kein Produktbericht. Er markiert einen Meilenstein.

22 Jahre im Testen, die letzten davon als Unternehmer. Ich habe Testautomatisierung in Versicherungen, im Maschinenbau und in der Energiebranche aufgebaut, immer mit demselben Auftrag: dafür sorgen, dass Software hält, was die Anforderung verspricht. Dieses Handwerk verändert sich gerade schneller als in den beiden Jahrzehnten davor.

Ich habe mich entschieden, diese Veränderung nicht abzuwarten. QET AI ist der sichtbare Teil davon. Qytera wandelt sich vom Dienstleister, der Testautomatisierung für andere aufbaut, zu einem Haus, das agentische Verfahren mitliefert und für ihre Nachweisbarkeit geradesteht. Das ist mehr als ein weiteres Werkzeug im Kasten. Es verändert, wie wir arbeiten, was wir anbieten und wofür wir einstehen.

Was sich nicht ändert: Am Ende steht ein Mensch, der die Freigabe verantwortet. Nach 22 Jahren im Testen weiß ich, dass genau daran alles hängt.

Wenn Sie das ausprobieren wollen

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.