Autor: Richard Seidl
“Es ist wieder Budget da. Es muss nur KI draufstehen.”
Richard Seidl
Testdatenmanagement erlebt grad eine Renaissance. Natürlich getrieben durch KI und die
Möglichkeiten, die man sich davon erhofft: bessere, passgenau Testdaten, einfache
Generierung, mühelose Verwaltung über Systemgrenzen hinweg. Da sprudelt es nur so vor
Ideen, was alles mögliche wird…oder wäre…oder naja vielleicht…hm.
Es gibt ja in der Softwareentwicklung ein paar Klassiker an Herausforderungen. Aber
während wir z.B. jene um Releases (Pipelines) und Testumgebungen (Cloud) halbwegs
gelöst haben, ist das mit Testdaten so eine Sache. Gerade in Applikationslandschaften mit
vielen unterschiedlichen Systemen und Datenhaltungen arten daher Testdateninitiativen
schnell einmal aus. Ist ja auch nicht einfach, denn die Herausforderungen sind ja
manigfaltig:
- Daten, Daten Daten – es sind einfach sehr viel. unzählige Tabellen und Felder und dazu tausende, manchmal sogar Millionen, Datensätze. Die alle Kreuz und Quer verlinkt und in Verzeichnissen noch irgendwelche Import/Export-Daten
- Kompatibilität – Jedes System hat sein Schema, seine Datenorganisation, die nicht zwangsläufig zueinanderpasst. Eine saubere Datenarchitektur über Systemgrenzen hinweg ist nicht einfach. Unterschiedliche Zuständigkeiten bringen dann noch zusätzliche Komplexität rein.
- Synthetische vs. Echt-Daten – Synthetische Testdaten helfen mir ungemein bei meinen strukturierten Testfällen (Grenzwerte, ÄKs, etc.) – aber sind halt auch nicht Realität. Und sobald man an Echt-Daten mit all ihren Besonderheiten, Fehlern etc. geht, steht der Datenschutz vor der Tür: Ano- und Pseudonymisierung brauchen wiederum viel Energie und Zeit.
- Wollen wir noch einen draufsetzen? Dann müssen unsere Testdaten auch noch Historisierung und Zeitreisen abbilden. Yeah – Jackpot.
Die KI wird’s schon richten, oder?
Aber alles gar kein Problem. Einfach alle Regeln, Anforderungen und Co in eine KI
schmeissen und dann generieren wir uns systemübergreifend und fast in Echtzeit unsere
Testdaten – ein Träumchen. Nur bin ich mir ziemlich sicher, dass das so einfach nicht
funktioniert. Es gibt schon ein paar ganz schöne Ansätze zur Generierung und Verwaltung
von Testdaten. Meine Beobachtung ist, dass hier aber ganz oft Symptombehandlung
betrieben wird. Ich würde da lieber zwei andere Fragen in den Raum stellen.
- Welche Daten brauche ich wirklich? (Und von diesen: welche brauche ich wirklich
wirklich?) – nur weil wir alles speichern können, heißt das noch lange nicht, dass wir
das müssen. Es ist so einfach ein Feld in einer Tabelle hinzuzufügen – die
Auswirkungen können aber dramatisch sein. Also: Einfach mal weglassen und alle
Strukturen löschen, die nicht benötigt werden. Eine (Test)datenradikalkur - Habe ich eine passende Daten-Architektur? Bei systemübergreifenden Architekturen
sehe ich viele Schnittstellen und Abhängigkeiten, aber kaum ein Gesamtbild der
Datenhalten, Datenflüsse und wo welche Daten sinnvoll abgelegt werden. Damit sie
nicht redundant und zirkulär abgelegt werden. So wird langsam ein Schuh draus.
Und sind die Daten halbwegs ordentlich, dann überleg mir mal irgendwas mit KI 😉
Ihr Richard Seidl
