Nachdem wir im Artikel #3 dieser Serie gesehen haben, wo und wie Künstliche Intelligenz (KI) bereits in der Testautomatisierung zum Einsatz kommt, geht es in diesem Artikel um die andere Seite der Medaille - Testen von Software, die von "künstlicher Intelligenz" gesteuert oder unterstützt wird. Was ist anders, was bleibt gleich?
Die alte Welt
Bei einer "klassischen", deterministischen Software, mit der ein Mensch interagiert, haben wir vereinfacht ein User-Interface (UI) und Peripherie-Geräte für Ein- und Ausgabe (Bildschirm, Tastatur, Schreibpad, etc.), die Core-Software, in der die eigentliche Verarbeitung geschieht, etwas um Daten zu speichern und vielleicht Schnittstellen zu Umsystemen.
Die Entwickler führen Unit-Tests durch, später folgen Systemtests (ST) und System-Integrationstests (SIT). Mit funktionalen Tests stelle ich fest, ob die Ergebnisse so sind, wie ich sie erwartet habe und mit den Tests für die nicht-funktionalen Anforderungen, ob zum Beispiel die Durchlaufgeschwindigkeit eines Geschäftsprozesses im vordefinierten Zeitrahmen liegt. Die User testen, ob das System für sie akzeptabel ist (UAT) und die Entscheider beim Kunden, ob sie das neue System abnehmen und bezahlen wollen.
Wenn man jetzt bei diesem System die handkodierte Entscheidungslogik durch eine probabilistische "Künstlichen Intelligenz" ersetzt, habe ich weiterhin mein UI und meine Peripherie-Geräte, etwas um Daten zu speichern und Schnittstellen. Nur in der Core-Software sieht es etwas anders aus. Wenn der Core modular aufgebaut ist, dann hat sich vielleicht sogar nur das Modul "Verarbeitungslogik" geändert, welches weiterhin über die gleichen internen Schnittstellen mit den anderen Modulen kommuniziert.
In kurz, der Unterschied zwischen einem System mit deterministischer Steuerung und einem KI-gesteuerten System ist genau die Steuerung selber. Die restlichen Komponenten bleiben gleich.
Weil sich sonst nichts ändert, müssen weiterhin Unit-Tests gemacht werden, genau wie die STs, SITs und UATs und der Bezahler wird es sich wahrscheinlich auch weiterhin nicht nehmen lassen Abnahmetests durchzuführen.
Fazit: Das "klassische" Testhandwerk hat weiterhin vollumfänglich Bestand und ändert sich für den grössten Teil der Software nicht, egal ob das Ausgabe-Ergebnis ganz old-school mit einem Entscheidungsbaum oder zum Beispiel durch ein neuronales Netzwerk ermittelt wird.
Die Tester werden jetzt die Hand heben und sagen, dass mit den Abnahmetests doch noch lange nicht Schluss ist, es fehlen doch noch die Regressionstests. Stimmt Kollegen, und hier haben wir (vielleicht) den ersten Unterschied.
Wenn ich bei einer deterministischen Software nichts aktiv im Code verändere, dann ändert sich nichts: "x > 5 == true" wird bei x == 6 heute richtig sein, morgen und auch noch in zehn Jahren. Eine Änderung muss aktiv durchgeführt werden (Update, Virus, etc.). Um sicher zu sein, dass nach der Änderung, die (hoffentlich) in Release Notes dokumentiert ist, noch alles korrekt läuft, gibt es die Regressionstests, laut ISTQB: "Erneutes Testen eines bereits getesteten Programms bzw. einer Teilfunktionalität nach deren Modifikation. … Ein Regressionstest wird durchgeführt, wenn die Software oder ihre Umgebung verändert wurde."
Man würde also hier vielleicht einen Regressionstestfall zur Prüfung des Grenzwertes "5" haben.
Die neue Welt
Bei probabilistischer Software liegt der Fall etwas anders. Ein Merkmal ist, dass die "Künstliche Intelligenz" nicht per se programmiert ist, sondern ein Rechenmodell trainiert wird. Es gibt einen Tag T, an dem der Kunde die Software abnimmt und das System in Produktion geht. Auch hier ist der Code fix bis zur nächsten Veränderung. Diese Veränderung kommt aber nicht nach Wochen mit einem Update-Projekt oder Bugfix, mit Code-Änderungen die ein Entwickler erstellt und irgendwo dokumentiert hat.
Im Normalfall lernt die "Künstliche Intelligenz" von dem Moment der Produktivsetzung an kontinuierlich on-the-job und ohne Entwickler weiter, sprich sie verändert sich ständig. Jeder Zustand ist daher länger "Ist-gewesen", als "Ist", da die Veränderungen mit jeder Operation kommen können. Dokumentation der Veränderung? Fehlanzeige.
Das vergleichbare Äquivalent zu unserem Statement von oben kann also nach einigen Tagen in Produktion vielleicht "x > 4 == true" lauten, aber vielleicht ist es auch immer noch "x > 5 == true" oder das Statement wurde komplett gestrichen.
Ein Regressionstest, der den Grenzwert abprüfen wollte, oder gar eine gezielte Anpassung des Regressionsfalles, ist also ebenfalls nicht möglich. Oder doch?
Regressionstestfälle für "Künstliche Intelligenz"?
Wie wir im ersten Artikel dieser Serie gelernt haben, gibt es drei grundsätzlich verschiedene Formen, wie man das Datenmodell der "Künstliche Intelligenz" trainieren kann.
- Supervised Learning: Beim Training der "KI" wird für jedes Beispiel die richtige Antwort mitgeliefert (labelled data), z. B. hat beim Erlernen von Handschriftenerkennung die Bilddatei, welche eine 3 darstellt, auch ein Label "3".
- Unsupervised Learning: Die "KI" muss ohne Hilfe selber Muster und Regeln in den Trainingsdaten finden (unlabelled data). Hier wird vor allem nach Anhäufungen und Korrelationen gesucht (Clustering), z. B. bei der Analyse von Kundenverhalten.
- Reinforced Learning: Prinzip Zuckerbrot und Peitsche. Der "KI" wird mittels "Belohnung" und "Bestrafung" beigebracht, was eine richtige und was eine falsche Antwort ist. Was die richtigen Antworten gemeinsam haben, muss die "KI" selber herausfinden.
Supervised Learning und Regressionstests
Bei der Durchführung eines Testfalles ist hier das erwartete Ergebnis klar definiert. Die Daten haben ein Label und die Bewertung binär möglich – "pass" oder "fail". Wir haben es hier also mit einem klassischen Regressionstest zu tun und dazu mit der unterschwelligen Erwartung, dass die Rate der "Fails" durch das permanente Training der "KI" über die Zeit noch abnimmt.
Da das Training aber permanent ist, muss man, im Gegensatz zur deterministischen Software, wo der Regressionstest eine Reaktion auf die Aktion der bewussten Code-Veränderung ist, den Regressionstest der "KI" per Zeitintervall planen, nur alle x Wochen oder vielleicht jede Nacht. Wie gross x ist, hängt zum Teil vom Gesamtsystem und seinen Komponenten ab, zum Teil vom Vertrauen in das System selber.
Bei unserer Handschriften-Erkennung beginnt der Geschäftsprozess damit, dass Papierbelege in einen Scanner eingezogen und gescannt werden. Lange bevor das KI-System ans Werk geht, gibt es schon viele Parameter, die das finale Ergebnis nachhaltig beeinträchtigen können: Farbe des Papiers, Farbe und Stärke des Kugelschreiber-Strichs, Verunreinigungen an der Scannerlinse, etc.
Ein End-to-end Regressionstest ist also ein echter Gesamtsystem-Test und bei einer Zunahme der "Fails" muss genau analysiert werden, in welcher Komponente die Ursache liegt.
Reinforced Learning und Regressionstests
Auch bei Systemen, die per "Reinforced Learning" trainiert wurden, gibt es ein definiertes, erwartetes Ergebnis. Bei einer Bankenanwendung für Fraud-Detection wird zum Beispiel erwartet, dass sie genau alle die Buchungen sperrt, die als "betrügerisch" erkannt wurden.
Das Ergebnis kann dabei in eine von vier Rubriken fallen: positiv (korrekt erkannt), falsch-positiv (fehlerhafterweise markiert), negativ (korrekterweise nicht markiert) und falsch-negativ (einen Positiven nicht markiert).
Bei dem Bankbeispiel wird jeder markierte Geschäftsfall von einem Menschen geprüft. Die Regressionstestfälle auf positiv und falsch-positiv werden also ständig im Arbeitsalltag durchgeführt (nur das sie dort "Positiv-Kontrolle" oder ähnlich heissen). Die Statistik am Tagesende zeigt, wie gut die Erkennungsrate auf dieser Seite war.
Auf der anderen Seite werden die Falsch-Negativen erst erkannt, wenn ein Betrugsfall aufgedeckt und mit Buchungen, die durch das System liefen, in Verbindung gebracht werden kann. Der Rest der Negativen muss als korrekt-negativ bzw. potenziell falsch-negativ angenommen werden (je nachdem, ob man Programmierer oder Auditor ist, variiert die Sicht etwas).
Die Qualität der Arbeit der "KI" kann im Negativbereich also nur durch KI-Testdaten festgestellt werden, analog der Tests im Projekt. Wir führen hierfür also wieder zeitgesteuerte Regressionstests durch.
Unsupervised Learning und Regressionstests
Unsupervised Learning wird für Mustererkennung eingesetzt. Gesucht werden Korrelationen zwischen Daten, und das "fliessende" Ergebnis wird in Prozentzahlen ausgedrückt. Hier gibt es kein richtig oder falsch mehr – ausser eine nachweislich vorhandene Korrelation wird nicht erkannt.
Jetzt sind wir wirklich bei unserer Annahme von oben angekommen: Regressionstests sind nicht möglich. Ich muss KI-Tests, vergleichbar zum Projekt, machen.
Auch für KI-gesteuerte Systeme gibt es Updates
Es gibt noch einen weiteren Aspekt für Regressionstests von KI-gesteuerten Systemen, den wir bisher noch gar nicht genannt haben. Ja, das KI-Modell lernt ständig weiter, "on-the-job". Nur, wie bei jeder anderen Software, ist es auch bei einer KI-gesteuerten Software lediglich nur eine Frage der Zeit, bis jemand zusätzliche Daten verarbeiten will oder es für eine Komponente ein Update gibt.
Die Updates können auf beiden Seiten des Systems sein. Es wird vielleicht eine neue Datenbankversion installiert, der Vertrieb will ein zusätzliches Adressfeld speichern oder für das Kredit-Rating will das Controlling jetzt vom Kreditantragsteller auch noch auswerten, wie lange der Kunde schon unter seiner aktuellen Adresse wohnt, wofür das KI-Modell und seine Eingabe-Schnittstelle erweitert werden müssen.
An dieser Stelle sind wir dann wieder beim üblichen Geschäft angekommen. Das System wird verändert und wir führen umfängliche Regressionstests durch, für alles was sich nicht ändern soll, und unsere eingangs aufgeführten Tests für die Neuerung und Anpassungen.
Zusammenfassend kann man also bis hierher sagen, dass uns beim Testen von Systemen, die von einer "Künstlichen Intelligenz" unterstützt oder gesteuert werden, der heutige Testprozess für den konventionellen Teil der Software erhalten bleiben wird. Bei den Regressionstests ändert sich auch nicht so viel, während für den KI-Teil des Systems zusätzlich ein zeitgesteuerter Auslöser dazukommt.
Für die "KI"-Steuerung selber gibt es noch einen ganz neuen Bereich, der ebenfalls regelmässig getestet werden muss. Die Stichworte dazu lauten "Bias" und "Drift". Was es damit auf sich hat, behandeln wir im fünften Teil dieser Artikelserie.
Dieser Artikel ist eine Gemeinschaftsarbeit von Olaf Lipinski, Wilhelm Kapp und Dejan Husrefovic, SwissQ Consulting, Dezember 2020.
Quellen:
https://www.german-testing-board.info/wp-content/uploads/2016/08/CT_Glossar_DE_EN_V23.pdf geprüft am 17.07.2020
