Testdaten in den Griff bekommen: ein pragmatisches How-to

Fragt man, warum ein Team seinen automatisierten Tests nicht vertraut, landet man erstaunlich oft bei derselben Ursache: Testdaten. Tests scheitern, weil der gestrige Lauf die benötigte Order verbraucht hat, weil der maskierte Datenbestand drei Monate alt ist, oder weil niemand die Produktion kopieren darf (DSGVO). Hier der pragmatische Ausweg.

Warum Testdaten die Automatisierung brechen

Neben Timing- und Synchronisationsproblemen, den klassischen Hauptursachen instabiler Tests (Luo et al., FSE 2014), gibt es einen oft übersehenen Treiber: deterministische Tests gegen nicht-deterministische Daten. Geteilte Umgebungen verändern sich unter der Hand: Ein anderes Team bucht das Konto, das Ihr Test erwartet, ein Nachtjob archiviert die Order, die Sie stornieren wollten. Und die klassische Abkürzung (Produktion kopieren) ist meist tabu: Personenbezogene Daten in Testsystemen verletzen die DSGVO, sofern sie nicht sauber anonymisiert sind.

Vier Datenklassen

Bevor Sie Tools wählen, sortieren Sie, was Ihre Tests brauchen, in vier Klassen. Jede braucht einen anderen Mechanismus:

Statische Werte: feste Werte, die sich selten ändern, etwa Ländercodes, Produkttypen oder Konfigurationseinstellungen. Teilen Sie sie, aber halten Sie sie aus einzelnen Testschritten heraus, damit ein geänderter Wert nicht fünfzig Tests bricht.
Dynamische Werte: zur Laufzeit erzeugt oder gelesen, etwa das heutige Datum, eindeutige IDs oder eine Nummer, die das System gerade vergeben hat. Nie hart codieren: Ein festes Datum ist der klassische Test, der grün ist, bis er es nicht mehr ist.
Wiederverwendbare Datensätze: Datensätze, die viele Tests lesen, ohne sie zu verändern, etwa ein Referenzkunde oder ein aktiver Vertrag. Einmal bereitstellen, dokumentieren und sicherstellen, dass kein Test sie verändert.
Verbrauchende Datensätze: Datensätze, die ein Test aufbraucht oder verändert, etwa eine offene Order zum Stornieren oder ein neues Konto zum Aktivieren. Sie brauchen Zustandsverwaltung, Sperren für parallele Läufe und Nachschub.

Vier Prinzipien

Tests besitzen ihre Daten. Das verlässlichste Muster: Jeder Test erzeugt (oder bestellt), was er braucht, etwa ein Konto, eine Order oder eine Buchung, und hängt nicht von Resten ab. In unserer SAP-Migrationsarbeit haben wir Daten aus genau diesem Grund per Tosca über die Anwendung angelegt.
Maskieren statt kopieren. Wo produktionsnahe Daten wirklich nötig sind: Maskierung/Anonymisierung, sodass keine reale Person identifizierbar ist, und dokumentieren; das ist Ihre DSGVO-Position.
Subset statt Klon. Ein referenziell konsistenter 2-Prozent-Ausschnitt lädt in Minuten, lässt sich nächtlich auffrischen und deckt funktionales Testen besser ab als der Terabyte-Klon, der immer veraltet ist.
Edge Cases synthetisieren. Der Kunde mit 40 Konten, der Schalttags-Geburtstag, der Name voller Umlaute: Synthetische Generierung liefert, was die Produktion rechtlich nicht darf und der Zufall selten hergibt.

Fünf Schritte zum Start

1. Inventur: Nehmen Sie Ihre 20 wichtigsten automatisierten Tests und schreiben Sie auf, welche Daten jeder wirklich braucht. Die Liste ist immer kürzer (und unordentlicher) als gedacht.
2. Klassifizieren: statischer Wert, dynamischer Wert, wiederverwendbarer oder verbrauchender Datensatz.
3. Je Klasse entscheiden: zentrale Parameter für statische Werte, Laufzeit-Ausdrücke für dynamische Werte, ein geteiltes Read-only-Set für wiederverwendbare Datensätze, Create-on-Demand oder ein verwalteter Pool für verbrauchende Datensätze. Wo produktionsnahe Daten nötig sind, speist ein maskiertes Subset den Pool.
4. Bereitstellung automatisieren: Daten-Setup ist Teil des Testlaufs, kein manueller Vorab-Schritt auf einer Wiki-Seite.
5. Messen: Die Quote der Fehlalarme vorher und nachher vergleichen. Mit dieser Zahl überzeugen Sie das Management.

Unsere Einschätzung

Testdatenmanagement ist kein Tool-Kauf, sondern eine Design-Entscheidung je Datenklasse, und sie zahlt in Vertrauen zurück: eine Suite, die nur rot wird, wenn wirklich etwas kaputt ist. Tools helfen bei der Umsetzung (in Tosca bilden TestCase-Design und Test Data Service diese Klassen direkt ab; Open-Source-Stacks kombinieren Generatoren und Maskierungs-Bibliotheken), aber die Klassifizierung kommt zuerst. Sie wollen wissen, wo Ihre Automatisierung Vertrauen verliert? Ein QA Health Check schaut genau darauf. Oder starten Sie ein Gespräch.