KI-Testen bedeutet, ein KI-System als Komponente im Gesamtsystem zu prüfen, nicht das Modell selbst. Die zentrale Weiche ist die Frage nach Determinismus: Verhält sich das System bei gleichem Input immer gleich, gelten klassische Testmethoden unverändert. Ist es nicht-deterministisch, braucht es statistische Kennzahlen und abgestimmte Testdatensätze zwischen Tester und Data Scientist.
Das Wichtigste in Kürze
- Ob ein KI-System deterministisch oder nicht-deterministisch ist, entscheidet die gesamte Teststrategie: Bei deterministischem Verhalten ändern KI-Komponenten am Testansatz praktisch nichts.
- Tester und Data Scientists haben überlappende Aktivitäten beim Erstellen von Testdaten, weshalb enger Austausch zwischen beiden Rollen die Qualität der Trainingsdaten direkt verbessern kann.
- Statistisches Grundwissen ist für Tester kein Nice-to-have mehr, weil KI-Systeme funktionale Outputs per Design nur mit einer bestimmten Wahrscheinlichkeit liefern und klassische Pass/Fail-Logik allein nicht ausreicht.
- Modellupdates erfordern eigene, kleinere Testdatensätze, um sicherzustellen, dass ein System sich nach dem Nachtrainieren nicht unkontrolliert in eine unerwünschte Richtung entwickelt.
Die wichtigste Frage zuerst: Ist das System deterministisch?
Bevor du dir Gedanken über statistische Methoden, Modell-Interna oder neue Testwerkzeuge machst, klär eine einzige Sache: Verhält sich dein System deterministisch? Diese Frage entscheidet über deine komplette Teststrategie.
Wenn das System deterministisch ist, hat sich für dich als Tester fast nichts geändert. Du hast funktionale Requirements und eine Subkomponente, die ihren Job erledigt. Ob dahinter KI, Machine Learning oder lineare Regression steckt, ist dann zweitrangig. Das Ding muss sich bei gleichem Input immer gleich verhalten, also kannst du feste Input-Output-Paare definieren und damit testen.
Manchmal ist ein System nur eingeschränkt deterministisch. Vielleicht ändert sich der Output auf denselben Input nur dann, wenn das Modell neu trainiert wird. Passiert das einmal im halben Jahr, kannst du mit fixen Testdaten arbeiten und musst dir lediglich rechtzeitig vor dem nächsten Modell-Release die Frage stellen, ob deine Annahmen noch passen.
Erst wenn die Antwort klar “nicht deterministisch” lautet, wird es aufwendiger. Dann landest du bei der Frage, wie oft du einen Testfall ausführen musst, um statistisch sicher zu sein, dass deine Annahmen erfüllt sind. Im Kern ist das aber ein Öftermacher des Bekannten, kein völlig neues Spiel.
Warum Nondeterminismus auch ohne Modelländerung auftreten kann
Ein fixes Modell garantiert noch kein deterministisches Verhalten. Auf unterschiedlichen Rechnerarchitekturen kann dasselbe Modell unterschiedliche Ergebnisse liefern, selbst wenn am Modell selbst nichts verändert wurde.
In so einem Fall musst du genauer hinschauen: Wo läuft das System? Ist die Hardware konstant? Welche Algorithmen laufen bei Matrix-Operationen in der GPU? An dieser Stelle wird Testen unangenehm, weil sich Race Conditions zwischen Recheneinheiten einschleichen können.
Oft kannst du dich aber zurück auf einen deterministischen Fall ziehen. Läuft das System on-premise auf fixer Hardware, brauchst du vielleicht gar keine GPU-Beschleunigung, sondern arbeitest mit Single-Core-CPU ohne Race Conditions. Dann ist die Reproduzierbarkeit wieder hergestellt. Genau deshalb lohnt es sich, früh zu klären, wo und auf welcher Hardware das Modell später tatsächlich arbeitet.
Tester und Data Scientists arbeiten an derselben Sache, aus zwei Richtungen
Der größte Hebel liegt im Gespräch zwischen Tester und Data Scientist. Beide Rollen haben überlappende Aktivitäten, sehen aber unterschiedliche Lücken.
Ein Data Scientist bekommt eine Problemstellung und entwickelt ein Modell, das genau dieses Problem löst. Er evaluiert mit mathematischen Methoden und stellt fest, dass das Modell funktioniert. Was dabei verloren gehen kann: Das Modell ist nur ein Teil eines größeren Systems, das eine bestimmte Funktion erfüllen soll. Eine Betriebsblindheit setzt schnell ein nach dem Motto “Modell fertig, evaluiert, also fertig”.
Genau hier kommt der Tester ins Spiel. Er bringt den Blick auf das Gesamtsystem mit und prüft, ob die Annahmen aus dem Training auch zur späteren Anwendung passen. Er kann die Boundary Conditions der Daten benennen, die beim Training noch nicht bedacht waren.
Diese Boundary Conditions können einen Data Scientist überglücklich oder todunglücklich machen. Überglücklich, weil neue Ideen zu einem besseren Trainingsdatensatz führen. Todunglücklich, wenn klar wird, dass der bisherige Trainingsdatensatz für den Eimer war. Beides ist wertvoll, weil beides die Qualität nach vorne bringt.
Was Tester sich zusätzlich aneignen sollten
Statistik wird wichtiger. Wenn ein Modell nur zu einem gewissen Prozentsatz den erwarteten Output liefert, musst du verstehen, was das für deinen Test bedeutet. “Stats 101” reicht oft schon, um zu wissen, an welchen Stellen du nachfragen musst.
Steht auf einem Modell 99,9 Prozent Accuracy, ist die relevante Frage: Was bedeutet das genau, und reicht es für den Anwendungszweck? Begriffe wie Accuracy und Precision musst du nicht erfinden, aber einordnen können.
Diese Methoden helfen dir konkret:
- Statistische und stochastische Methoden, um Wahrscheinlichkeits-Outputs zu bewerten
- Kombinatorisches Testen, das im KI-Umfeld an Bedeutung gewinnt
- Exploratives Testen, das ebenfalls wichtiger wird, nicht unwichtiger
Tiefes Wissen über die Arbeit des Data Scientists brauchst du dafür nicht. Es sind zwei getrennte Rollen mit zwei Skillsets. Wenn du wegen einer kleinen Firma beide Rollen bedienst, lohnt sich beides. Sonst genügt es, den Output der Modelle zu verstehen, weil genau dieser Output dein Testdesign und deine Teststrategie beeinflusst.
Der Unterschied zwischen Machine Learning, Deep Learning und anderen Verfahren ist nice to know. Es ist kein Pflicht-Skill für Tester, auch wenn viele es lernen wollen, weil das Thema gerade aktuell ist.
Wie viel von der KI musst du überhaupt verstehen?
Einen Großteil kannst du als Blackbox behandeln. Vollständig zu verstehen, was in einem Modell passiert, ist offenes Forschungsgebiet. Explainable AI gibt es nicht umsonst und ist nicht abschließend gelöst.
Du hast also gar nicht die Chance, immer alles zu verstehen. Du hast aber die Chance, es besser zu verstehen als am Anfang. Dafür stell dir die Frage: Welche Teile meines Systems nutzen überhaupt KI, und wo muss ich genauer hinschauen?
Die Lesbarkeit des Modells entscheidet, wie tief du manuell hineinkommst. Ist es ein Entscheidungsbaum, kannst du ihn je nach Breite noch durchgehen. Sind es tiefe neuronale Netze, deren Formeln Hunderte Seiten füllen würden, wird das für jeden schwierig.
Ein kleiner Ausschnitt der Basics ist trotzdem nützlich. Er gibt dir das Gespür, an welchen Stellen du nachfragen musst, und hilft dir, deine eigenen Blind Spots zu erkennen.
Warum die Frage “Brauchen wir überhaupt noch Tester?” geklärt ist
Ja, wir brauchen Tester. Die Frage kam in der Arbeitsgruppe auf, und manche Toolhersteller behaupten womöglich das Gegenteil. Die Antwort bleibt: Wir brauchen Leute, die mit dem Testfokus an ein System herangehen.
Dieser Fokus ist kein Beiwerk. Ein Data Scientist evaluiert sein Modell mit den Werten, die ihm sinnvoll erscheinen. Der Tester prüft, ob das im Gesamtsystem und im realen Anwendungsfall trägt. Diese beiden Blickwinkel ersetzen einander nicht.
Testdaten: Brauchst du ein Golden Dataset?
Beim Thema Testdaten lohnt sich erneut das Gespräch mit dem Data Scientist. Er hat bereits Trainingsdaten erzeugt, und du musst klären, was davon du wiederverwenden kannst und was du noch brauchst.
Frag dich, ob du dein System überhaupt immer auf demselben Datensatz testen musst. Vielleicht ist das gar kein Use Case, vielleicht ist es egal. Vielleicht musst du im Test auch das Training des Modells absichern. Dann einigt euch, was das Golden Dataset für Tester und was es für den Data Scientist ist.
Aktivitäten wie das Erstellen von Testdaten machen Data Scientists ohnehin schon, weil sie Daten für das Modelltraining brauchen. Dabei entstehen Datensätze, die du direkt fürs Testen hernehmen kannst, oder zumindest ein Gefühl, das dir später beim Generieren eigener Testdaten hilft.
Modell-Updates brauchen eigene Tests
Ein oft vergessener Punkt: Wenn das System durch Mechanismen weiterlernt, brauchst du kleinere Datasets, um Updates zu simulieren. Damit stellst du sicher, dass die Entwicklung in die richtige Richtung läuft und zur Realität passt.
Die Beispiele von Chatbots, die in die Freiheit gelassen werden und sich in kurzer Zeit zu interessanten Persönlichkeiten entwickeln, zeigen, was passiert, wenn dieser Fall ignoriert wird. Wie verhält sich ein selbstlernendes Modell unter Update-Bedingungen? Wird das nicht getestet, kann genau so etwas schiefgehen.
Es gibt keine Silver Bullet, die dir sagt, ob du das brauchst. Aber stell dir die Frage. Und denk daran, dass es nicht nur um das initiale Test-Setup geht, sondern auch um kleinere Update-Test-Datasets für die laufenden Modelländerungen.
Vieles ist alter Wein in neuen Schläuchen
Nicht-deterministische Systeme gab es vor der KI. “Eventually consistent” Systeme aus dem Microservice-Umfeld zwingen dich schon lange, Testfälle so zu schneiden, dass sie nicht-deterministisches Verhalten verkraften.
Auch Statistik im Test ist nicht neu. Ein gutes Non-Functional Requirement zum Time Behaviour klingt etwa so: In 95 Prozent der Fälle soll die Webseite in unter 300 Millisekunden ausgeliefert werden. Wer Performance-Tests ernst nimmt, hat sich also längst mit Statistik herumgeschlagen.
Nur weil du jetzt ein KI-System hast, hast du ja hoffentlich nicht keine Requirements. Schau dir deine Requirements an und mach wieder deine ganz normalen Testmethodiken.
— Marco Achtziger
Was sich ändert, ist der Output der KI-Komponente. Die Schnittstelle liefert nicht mehr einfach B auf A, sondern B mit einer Wahrscheinlichkeit von x Prozent, dazu Kennzahlen wie Accuracy und Precision. Den Rest deines Werkzeugkastens nimmst du mit.
Klassifizierungsprobleme lassen sich mit bekannten Methoden testen
Viele KI-Aufgaben sind Klassifizierungsprobleme, und genau die kannst du mit etablierten Testmethoden abbilden. Du wirfst ein Bild hinein und willst wissen, ob es zu 90 Prozent eine Katze oder ein Hund ist.
Auf solche Fälle wendest du deine vorhandenen Methodiken an. Was sind die funktionalen Tests? Gibt es Grenzwerte zu beachten? Lassen sich Äquivalenzpartitionen identifizieren? Diese Fragen führen dich direkt in ein klares Testdesign.
Der häufigere Blocker ist nicht fehlende Technik, sondern Schockstarre und Angst vor dem Schlagwort. Wer das große Wort “KI” hört, denkt schnell an menschenähnliche Intelligenz und glaubt, er bräuchte einen Psychologen statt eines Testers. Genau dieses Riesengebilde gilt es herunterzubrechen auf etwas Greifbares: deine Requirements, deine Komponenten, deine bekannten Methoden und die eine zentrale Weiche zwischen Determinismus und Nondeterminismus.
