Testdatenmanagement ahoi

Vor wenigen Tagen wurde ich bezüglich eines Problems von einem Kunden zu einer Sitzung beordert. Dabei wurde lang und breit erläutert, dass wohl ohne Dokumentation und Information der Kunden neue Funktionen eingeführt worden seien oder bestehende komplett umgebaut. Den das Unternehmen X könne seine Testfälle nicht mehr ausführen und die Applikation sei «buggy». Man würde jetzt seit 4 Monaten testen und die Resultate seien sehr verstörend. Auf eine kurze Nachfrage wurde mir bestätigt, dass die Testdaten seit Anbeginn der Testaktivitäten nie zurückgesetzt oder erneuert worden waren.

Testdaten laufen ab!

Das Eskalationsmeeting endete damit, dass ich den Kunden bat, die aktuellen Testdaten für das Unternehmen X zu eliminieren, Testdaten neu zu erfassen und mit diesen neuen Daten zu testen. Und siehe da: Die Tests verliefen danach ohne weitere Probleme. Ja, Testdaten laufen ab. Sie haben zwar kein Verfallsdatum wie Lebensmittel, aber auch ihre Zeit läuft ab. Jede Verarbeitung verändert sie. Der Testfall baut aber auf dem Urzustand der Testdaten auf. Und so kann es so weit kommen, dass die Daten nach einer gewissen Zeit gar nicht mehr für Tests taugen. Das fühlt sich dann an wie ein Silo voller Schlüssel und keiner passt zum Schrank mit den Schleckereien.

Gibt es sowas wie einen Testdatenverbrauch?

Kurz: Ja. Obwohl abstrakt, versuche ich diesen zu erklären. Mit jeder Testausführung werden die Testdaten verändert. Dabei verhalten sich Testdaten wie Modelliermasse. Mit jedem Male, bei dem man die Masse in die Hand nimmt, hinterlässt man eine Spur. Zuerst einen einzelnen Abdruck, über die Zeit aber verändert sich langsam die Form. Und das führt dazu, dass man feststellt, dass die Modelliermasse nun komplett neu formatiert werden muss (einen runden Klumpen machen), auf dem man wieder mit der Arbeit beginnen kann. Wenn du jedoch einwirfst, dass das ja nur für Sekundär-Daten, also Transaktionen, gilt, halte ich dagegen, dass jede Transaktion auch die Primärdaten (also Stammdaten) verändert. Denn die beiden Datentypen stehen ja in einer Wechselwirkung oder aber die Primärdaten verändern sich über die Zeit (z.B. Alter einer Person).

Welche Auswirkungen hat ein unkontrollierter Testdatenverbrauch?

Die erste Auswirkung ist offensichtlich: Man findet immer weniger Datensätze, die sich potenziell für eine Testfall-Ausführung eignen. Später zeigen die Tests unlogische oder keine Resultate oder aber es werden Fehlermeldungen provoziert, die nicht nachvollziehbar sind. Es kann ad extremis aber so weit kommen, dass keine Tests mehr ausgeführt werden können, weil die Testdaten gar nicht mehr passen und somit für den Testfall keine geeigneten Daten mehr zur Verfügung stehen.

Wie lange ist das Ablaufdatum von Testdaten?

Eine generelle Aussage dazu ist schlicht unmöglich. Das hängt stark vom System unter Test, dem Test-Environment, aber auch der Menge der Testdaten ab. Nicht zuletzt trägt das System unter Test (SuT) erheblich dazu bei, ob und wie die Testdaten ‘abnutzen’. Aber auch die Testfälle sind nicht unschuldig und das Setup des Testsystems. Beispiel: Will man testen, wie sich das SuT in Bezug auf minderjährige Kunden verhält, wird die Anzahl potentieller Testdatensätze im SuT automatisch jeden Tag kleiner.

Wo ist die Gefahr am Grössten?

Die Gefahr ist da am Grössten, wo automatisierte Systeme mit statischen Testdaten (Primär- und Sekundärdaten) zu arbeiten haben. Dazu zählen Systeme im Rahmen von CI (Continuous Integration), aber auch Systeme mit grossen Testdatenbeständen. Denn diese wiegen den Testmanager in der falschen Sicherheit, dass es ja tausende von potentiellen Testdatensätzen gäbe. Das stimmt, aber oft wird davon ja nur ein kleiner Prozentsatz der Testdatensätze gebraucht. Und so kriegt man kaum mit, wenn die Testdaten alle sind.

Kann man den Testdatenverbrauch messen?

Na ja, leider hat ein Testsystem keine Testdaten-‘Tankuhr’, die anzeigt, wenn der Datentank leer ist. Aber es gibt Möglichkeiten, den Testdatenverbrauch zu kontrollieren. Dafür muss man aber wissen, was überhaupt im ‘Tank’, sprich Testdaten, war und wovon wie viel noch vorhanden ist. Um das zu beherrschen, muss das Testdaten-Management so aufgebaut sein, dass dieses jederzeit weiss, welche Testdaten wie in welchem System sind, wann es das letzte Mal ‘befüllt’ wurde und mit wie viel von was, und wer wie viel davon schon aufbrauchte.

Geht das auch pragmatischer?

Jeder würde nun sagen: Logo. Wir setzen einfach die Testdaten zurück oder aber wir laden die Testdaten einfach neu. Schade nur, dass das nicht immer zum gewünschten Erfolg führt. Denn die Tests haben sich allenfalls selbst weiterentwickelt oder aber die Datenstruktur wurde angepasst/erweitert/verändert. Und dann passen die Daten nicht mehr. Fakt aber ist: auch wenn du das pragmatisch löst, musst du die Kontrolle über die Testdaten erlangen. Und das geht nur, wenn man diese kennt. Wenn man einfach eine Kopie neu lädt, hat man da eine Chance verpasst oder lädt sich neue Fehler.

Und warum soll der Testdatenverbrauch gemessen werden?

Die Messung des Testdatenverbrauchs hilft dir nicht nur zu evaluieren, ob du noch genug Testdaten im ‘Tank’ hast. Es hilft auch, die Testdaten-Abdeckung zu evaluieren und an das Testmanagement zu rapportieren, wenn gewisse Testdatenkonstellationen gar nicht getestet werden. Denn werden diese nicht getestet, sind entweder die Tests nicht komplett oder die Testdaten nicht nötig und man hat übermässig Kosten im Bereich Infrastruktur verursacht. Beides sind auf jeden Fall ungewünschte Auswirkungen.

Wie gehst du mit dem Problem um?

Kennst du diese Problematik, sei es als Problem oder als jemand, der das gelöst hat? Was sind deine Erfahrungen damit? Gibt es eine ‘Best-Practice’ aus deiner Sicht oder ist diese Problematik situativ zu lösen? Teile uns deine Erfahrung mit.