Ein Gespräch mit Danny Tamm, Programmierer und Consultant bei UBS-Hainer beschreibt die grundlegende Herausforderung bei der täglichen Beschaffung qualitativ hochwertiger Testfalldaten. Die gute Nachricht vorab: Es gibt eine elegante Lösung, durch die sich die Tester voll und ganz auf das Testing konzentrieren können. Die benötigten Daten kommen dann bedarfsgerecht ganz automatisch.
Q: Danny, das Testing ist ja heute beim Continuous Development ein regelmäßiger und wichtiger Faktor für die Software-Qualität. Worin genau liegt hier die Herausforderung?
Danny Tamm: Na ja, die Daten müssen halt genau passen: Ich muss meine Software bzw. einzelne Komponenten während der Entwicklung immer wieder testen, um negative Überraschungen bei der Implementierung zu vermeiden. Also habe ich mir einen Test ausgedacht, der ein bestimmtes Verhalten testen soll. Und um sicherzustellen, dass der Test realitätsnah ist, brauche ich Daten, die exakt dem Szenario entsprechen, das ich prüfen möchte.
Ohne diese Daten, kann ich den Test nicht durchführen. Also stellt sich jetzt die Frage: Wie komme ich an diese Daten? Wo liegen diese Daten, und welche Parameter sind damit verknüpft? Die Herausforderung für viele Tester liegt darin, spezifische Testdaten zu finden, ohne die genaue Struktur der Datenbank zu kennen. Sie wissen also nicht, in welcher Tabelle oder Datenbank die gewünschten Informationen abgelegt sind oder wie die Beziehungen zwischen diesen Daten aussehen.
Q: Wie kann man sich das praktisch vorstellen?
Danny Tamm: Ein typisches Beispiel bei einer Versicherung wäre: ein Kunde, der in Berlin wohnt, verheiratet ist, zwei Kinder hat und zwei Versicherungsverträge besitzt: einen für ein Auto und einen für ein Haus. Genau solch einen Datensatz bräuchte ich, z.B. weil die Software in diesem Fall verschiedene spezifische Vertragsbedingungen vergleichen soll. Aber wie finde ich diese Daten in einer großen Datenbank.
In der Praxis existieren oft Millionen von Datensätzen, und jeder einzelne Kunde hat eine Vielzahl von Attributen. Diese liegen aber nicht an einer Stelle, sondern sind auf verschiedene Tabellen oder gar Datenbanken verteilt. Es gibt vielleicht eine Tabelle für Kundendaten mit Angaben wie Name und Adresse, eine andere für Verträge, die wiederum unterschiedliche Versicherungsarten und -details enthält.
Die Herausforderung liegt also in der Komplexität und Verteilung der Daten. Einfache Kriterien wie „alle Kunden in Berlin“ kann man schnell und problemlos abfragen. Ebenso ist es kein Problem, Kunden zu finden, die irgendeine Art von Versicherungsvertrag besitzen. Aber die Kombination all dieser Attribute – ein Berliner Kunde, der verheiratet ist, zwei Kinder hat, zwei bestimmte Verträge besitzt und in einem Mehrpersonenhaushalt lebt – erfordert, dass bei der Suche alle relevanten Datenquellen miteinander verknüpft werden.
Q: Und wie macht man das ohne Automatisierung?
Danny Tamm: Die traditionelle Methode besteht darin, Datensätze händisch herauszusuchen. Das ist nicht nur zeitaufwändig, sondern erfordert auch detaillierte Kenntnisse über die Datenbankstruktur. Tester können das i.d.R. nicht bewältigen. In der Praxis kommen dann häufig vorgefertigte Listen mit Standard-Datensätzen zum Einsatz, die immer wieder verwendet werden. Natürlich können diese die komplexe Realität und Dynamik echter Produktionsdaten nicht abbilden. Zudem wird es problematisch, wenn mehrere Tester denselben Datensatz benötigen.
Q: Das kann doch aber auf Dauer nicht die Lösung sein, insbesondere, wenn immer mehr und in immer komplexeren Systemen getestet werden muss, oder?
Danny Tamm: Meines Erachtens ist es tatsächlich nicht machbar, ohne Automation vernünftige Daten zu generieren bzw. es ist definitiv nicht sinnvoll. Wir haben das selber mal ausprobiert, weil wie sehen wollten, wie aufwendig es ist, komplexe Testdaten ohne bestehende Datenquellen selbst zu generieren.
In diesem Experiment haben wir versucht, neun Tabellen mit insgesamt 100.000 Datensätzen so realitätsnah wie möglich zu befüllen – und das hat uns fast drei Wochen gekostet. Anfangs schien es einfach: Ein Kunde hatte in unserem Szenario beispielsweise fünf bis sechs Attribute, wie Name, Alter, Adresse und Bankverbindung. Aber in einer produktiven Umgebung hat ein Kunde meist nicht nur ein paar, sondern bis zu 50 Attribute.
Und da hört es nicht auf – jede Adresse hat weitere, teilweise untergeordnete Attribute, und Verträge bringen noch mal eine ganz andere Ebene mit, die hunderte von Details umfassen können, z.B. Laufzeiten, Vertragsbedingungen, Zahlungsverläufe und Historien. Sich hier eine Handvoll Datensätze auszudenken ist möglich, aber die Herausforderung wächst exponentiell mit der Zunahme der Komplexität. Die Daten dürfen ja nicht identisch ein.
Jedes Attribut muss man sich so überlegen, dass es noch natürlich wirkt und gleichzeitig nicht zu repetitiv oder untypisch ist. Die Kombinationen aus Alter, Vertragsarten, Adressinformationen, Familienstand usw. sollen ja realistisch und einzigartig bleiben. Es ist unmöglich ohne extremen Aufwand, eine produktive Umgebung wirklich realistisch nachzubilden. Und dabei ist es ja keine produktive Zeit, sondern nur die Vorbereitung für einen Test.
Q: Und wie sieht es mit synthetischen Daten aus, die einfach künstlich erzeugt werden? Könnte das nicht die Lösung sein?
Danny Tamm: Das geht theoretisch, aber wenn du alles synthetisch generierst, dann hast du eben künstliche Daten. Und das ist ganz sicher nicht die beste Lösung. Denn es gibt einen wichtigen Aspekt, den synthetische Daten nicht hinbekommen können: realistische Randfälle.
Q: Ok, und was heißt das?
Danny Tamm: Um beim Versicherungsbeispiel zu bleiben: Da gibt es Verträge, die 30 Jahre alt sind und durch zahlreiche Software-Migrationen und -Updates gegangen sind. Solche Daten haben besondere Konstellationen, die man in einer künstlich erzeugten Datenbank nicht ohne weiteres simulieren kann. Diese Randfälle sind für Tests aber essenziell, da sie Situationen abdecken, die besonders anfällig für Fehler sind.
Genau da zeigt sich, dass synthetische Daten eben nicht die Komplexität und Vielfalt von Echtdaten erreichen. Sie können jedoch sinnvollerweise bei Massentests eingesetzt werden, bei denen es weniger auf individuelle und komplexe Testdaten ankommt. Zum Beispiel für Lasttests, bei denen man Tausende Datensätze braucht.
Q: XDM von UBS Hainer löst dieses Problem ganz elegant mit dem Test Data Finder. Was bedeutet das für den einzelnen Tester, wenn er mit diesem Tool arbeitet?
Danny Tamm: Ja, das ist einer der großen Vorteile bei XDM. Der Tester gibt hier einfach die benötigten Attribute an: „Kunde in Berlin, verheiratet, zwei Kinder, Auto- und Hausversicherung“. Der Testdatenfinder durchsucht dann automatisch die vorhandenen Tabellen und Datenbanken nach Datensätzen, die diese Kriterien erfüllen, und erstellt eine Liste mit passenden Ergebnissen. Das erspart eine mühsame, manuelle Suche. Der Tester hat sofort eine Auswahl an Datensätzen, aus denen er für seine Tests den passenden auswählen kann.
Diese Funktion ist nicht nur effizienter, sondern minimiert auch Fehler, da der Testdatenfinder systematisch und präzise arbeitet – im Gegensatz zu einer rein manuellen Suche, die besonders bei komplexen Kriterien leicht unvollständig sein kann. Und es handelt sich eben nicht um synthetische Daten, sondern qualitativ hochwertige Testdaten aus der Produktion. Diese werden vollautomatisch anonymisiert und maskiert und erfüllen so alle rechtlichen Datenschutz-Kriterien.
