KI testet — aber wer testet die KI?

In der klassischen Softwareentwicklung ist das Testobjekt klar definiert: ein System mit spezifizierten Anforderungen, determiniertem Verhalten und nachvollziehbarer Logik. Ein gut formulierter Testfall hat eine eindeutige Erwartung. Entweder das System liefert das richtige Ergebnis — oder nicht.

KI-Systeme spielen nach anderen Regeln.

Ein Large Language Model gibt bei identischer Eingabe heute eine andere Antwort als gestern. Ein Bildklassifizierungsmodell trifft in 98% der Fälle die richtige Entscheidung — aber in welchen 2% liegt es falsch, und warum? Ein Empfehlungssystem optimiert auf Klickrate, obwohl es eigentlich Kundenzufriedenheit maximieren sollte. Diese Systeme sind nicht falsch programmiert. Sie sind so gebaut. Und genau das macht das Testen fundamental anders.

Die Qualitäts-Community steht vor einer Herausforderung, für die die klassischen Methoden nur teilweise gerüstet sind: Wie testet man ein System, dessen Verhalten probabilistisch, kontextabhängig und durch Trainingsdaten geprägt ist — nicht durch explizite Logik?

Betrachten wir drei Grundprinzipien des professionellen Testens — und was mit ihnen passiert, wenn das Testobjekt ein KI-System ist:

Reproduzierbarkeit: Ein klassischer Test liefert bei gleichen Bedingungen stets das gleiche Ergebnis. Bei generativen KI-Systemen ist das nicht garantiert. Einflussfaktoren wie Temperatur-Parameter, Sampling-Strategien und Modell-Updates können dazu führen, dass ein Test, der gestern grün war, heute rot ist — ohne dass sich der Code geändert hätte. Flaky Tests (unzuverlässiger oder wackeliger Test) bekommen eine neue Dimension.

Erwartungswerte: Jeder Testfall braucht ein Oracle — eine definierte Erwartung. Bei KI-Systemen ist das Oracle oft unklar. Was ist die „richtige“ Antwort auf eine komplexe Kundenanfrage? Was ist eine „faire“ Kreditentscheidung? Diese Fragen sind keine technischen — sie sind ethische und fachliche. Das Testdesign beginnt nicht mehr im Testteam, sondern im Fachbereich, in der Ethikkommission oder im juristischen Review.

Qualitätsmerkmale: Damit werden ganz neue Prioritäten für die zu beachtenden Qualitätsmerkmale gesetzt, Ethik, Fairness und Voreingenommenheitsfreiheit zum Beispiel sind noch nicht einmal im ISO/IEC 25010 Standard enthalten. Zur Messung der Qualität der Systeme werden zusätzlich statistische Methoden benötigt, die im klassischen Quality Engineering keine Bedeutung haben. Der F1-Score als Beispiel ist eine zentrale Metrik in der Statistik und im maschinellen Lernen, um die Güte eines Klassifikationsmodells zu bewerten. Er wird als das harmonische Mittel aus Präzision (Precision) und Sensitivität (Recall) berechnet.

Abdeckung: Statement Coverage, Branch Coverage, Path Coverage — all diese Metriken setzen voraus, dass es einen definierten Codefluss gibt. Bei einem neuronalen Netz mit Millionen von Gewichten ist „Coverage“ kein sinnvolles Konzept im klassischen Sinne. Neue Metriken sind nötig: Abdeckung des Eingaberaums, Robustheit gegenüber Adversarial Inputs (konfrontative Eingaben) und Verhalten an Verteilungsgrenzen.

Die gute Nachricht: Das Testing-Handwerk ist nicht obsolet. Es muss erweitert werden. Hier sind Ansätze, die bereits heute anwendbar sind:

Metamorphic Testing: Wenn kein eindeutiges Oracle existiert, können Relationen zwischen Testfällen geprüft werden. Wenn ein Übersetzungssystem den Satz „Die Katze sitzt auf der Matte“ korrekt übersetzt, sollte die Übersetzung von „Die Katze sitzt nicht auf der Matte“ eine konsistente Verneinung enthalten. Nicht die absolute Antwort wird getestet — sondern die Konsistenz des Verhaltens bei definierten Transformationen der Eingabe.

Property-Based Testing: Statt einzelner Testfälle werden Eigenschaften definiert, die das System immer erfüllen soll — unabhängig vom konkreten Input. Ein Kreditentscheidungssystem sollte bei identischen Finanzdaten unabhängig von der ethnischen Herkunft des Antragstellers zu gleichen Ergebnissen kommen. Diese Eigenschaft lässt sich automatisiert mit tausenden generierten Testfällen prüfen.

Adversarial Testing: KI-Systeme können durch gezielte Manipulation der Eingabe zu falschen Ausgaben verleitet werden — sogenannte Adversarial Examples. Ein Bild, das für das menschliche Auge eindeutig eine Katze zeigt, kann durch minimale Pixel-Manipulation ein KI-System dazu bringen, „Hund“ zu klassifizieren. Sicherheitskritische KI-Systeme müssen auf diese Robustheit getestet werden.

Bias- und Fairness-Testing: Trainingsdaten spiegeln historische Realitäten — und damit historische Ungleichheiten. Ein Modell, das auf Bewerberdaten der letzten 20 Jahre trainiert wurde, kann strukturell bestimmte Gruppen benachteiligen. Bias-Testing bedeutet: systematische Überprüfung, ob das Modell über verschiedene demografische Gruppen hinweg konsistent und fair entscheidet. Werkzeuge wie IBM AI Fairness 360 oder Facets bieten hier erste methodische Unterstützung.

Monitoring als kontinuierliches Testing: KI-Systeme verändern sich auch im Feld — durch neue Trainingsdaten, Modell-Updates, veränderte Nutzungskontext. Ein einmaliger Test vor dem Go-Live ist nicht ausreichend. Produktions-Monitoring, das auf statistische Abweichungen im Modellverhalten reagiert (Data Drift, Concept Drift), ist eine Form von kontinuierlichem Testing — und muss als solche geplant und betrieben werden.

KI kann beim Testen helfen — Testfälle generieren, Logs analysieren, Anomalien erkennen. Das ist wertvoll. Aber KI kann nicht entscheiden, was ein faires Ergebnis ist. KI kann nicht abwägen, welches Risiko akzeptabel ist. KI kann nicht die Verantwortung für ein System übernehmen, das Menschen betrifft.

Diese Verantwortung liegt beim Menschen. Und sie liegt konkret bei denjenigen, die das Testing professionell betreiben.

Die Rolle des Quality Engineers verändert sich: weniger manuelle Testausführung, mehr Testdesign für nicht-deterministische Systeme. Weniger Skript-Pflege, mehr Risikobewertung und ethische Überprüfung. Weniger Fehlerbericht schreiben, mehr Qualitätsverantwortung in interdisziplinären Teams — gemeinsam mit Data Scientists, Fachbereichen und dem Legal-Team.

Das erfordert neue Kompetenzen. Und es erfordert, dass die Qualitäts-Community diese Entwicklung aktiv mitgestaltet — statt darauf zu warten, dass andere die Antworten liefern.

Eine offene Frage an die Branche

KI-Systeme treffen heute Entscheidungen, die Kredite vergeben, Krankheiten diagnostizieren, Bewerbungen aussortieren und autonome Fahrzeuge steuern. Die Frage, wie diese Systeme getestet werden — systematisch, nachvollziehbar, verantwortungsbewusst — ist keine akademische. Sie ist eine gesellschaftliche.

Die Qualitäts-Community hat das Handwerkszeug, das Denkvermögen und die Erfahrung, um hier eine führende Rolle einzunehmen. Die Frage ist, ob wir sie auch einfordern.

KI testet. Aber wer testet die KI — das sollten wir sein.