(Test)datenradikalkur

“Es ist wieder Budget da. Es muss nur KI draufstehen.” - Richard Seidl

Testdatenmanagement erlebt gerade eine Renaissance. Natürlich getrieben durch KI und die Möglichkeiten, die man sich davon erhofft: bessere, passgenaue Testdaten, einfache Generierung, mühelose Verwaltung über Systemgrenzen hinweg. Da sprudelt es nur so vor Ideen, was alles möglich 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 auch nicht einfach, denn die Herausforderungen sind mannigfaltig:

• Daten, Daten Daten – es sind einfach sehr viele. Unzählige Tabellen und Felder und dazu tausende, manchmal sogar Millionen, Datensätze. Die alle kreuz und quer verlinkt sind und in Verzeichnissen noch irgendwelche Import/Export-Daten enthalten.
• Kompatibilität – Jedes System hat sein eigenes Schema, seine eigene 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 wirds scho richten, oder?

Aber alles gar kein Problem. Einfach alle Regeln, Anforderungen und Co in eine KI schmeißen 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 Datenarchitektur? 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 ich mir mal irgendwas mit KI 😉