·
12 min
Testdatenmanagement: Testdaten planen, bereitstellen und schützen, auch für automatisierte Tests
Roman Kirchmeier - Autemos
Testdatenmanagement (TDM) ist die geplante Arbeit an Testdaten über den ganzen Testprozess: Bedarf klären, Daten spezifizieren, gewinnen, bereitstellen, schützen und am Ende archivieren oder löschen. Der deutschsprachige Lehrplan „Test Data Specialist“ des German Testing Board (GTB) gliedert das in 7 Aktivitäten und 3 Rollen (GTB-Lehrplan Test Data Specialist V1.1, 2021). Für automatisierte Tests gilt eine harte Bedingung: Die Daten müssen beim Start des Laufs bereitliegen, oft nachts und ohne Aufsicht. In Banken und anderen regulierten Unternehmen legt das Recht fest, welche Produktivdaten überhaupt in Testumgebungen liegen dürfen.
Kurz gefasst: Testdatenmanagement plant, beschafft, schützt und pflegt die Daten, die Tests brauchen. Der GTB-Lehrplan Test Data Specialist (V1.1) beschreibt dafür 7 Aktivitäten von der Planung bis zur Archivierung. Automatisierte Tests brauchen Daten auf Abruf und pro Test isoliert. EU-Finanzunternehmen dürfen in Nichtproduktionsumgebungen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten speichern (DORA-RTS Art. 16(5)).
Abbildung 1: Eingabe-, Zustands-, Ausgabe- und Soll-Daten im Testablauf
Was sind Testdaten?
Testdaten sind die Daten, die ein Test zur Ausführung braucht: Eingaben, vorhandene Datenbestände im System und die erwarteten Ergebnisse. Das offizielle ISTQB-Glossar definiert den Begriff in fünf Wörtern: „Data needed for test execution.“ (ISTQB Glossary, 2026). Der GTB-Lehrplan wird genauer: „Testdaten sind konkrete Werte von Datenobjekten, die zur Ausführung eines Testobjekts benötigt werden.“ (GTB-Lehrplan TDS V1.1, 2021)
Der Unterschied zwischen einem abstrakten und einem konkreten Testfall liegt in genau diesen Werten. Ein abstrakter Testfall arbeitet mit Parametern als Platzhaltern, etwa „Betrag“ oder „Kontotyp“. Erst konkrete Werte machen ihn ausführbar. Setzt man verschiedene Werte aus dem erlaubten Wertebereich ein, entsteht laut Lehrplan „eine Reihe von Testfallvarianten“. Auf dieser Idee beruht das datengetriebene Testen.
Der Lehrplan beschreibt Testdaten als „realistische Daten, aber keine realen Daten“, die „unauflöslich mit den Testumgebungen … verbunden“ sind. Ein Kunde, der in der Integrationsumgebung existiert, fehlt vielleicht in der Abnahmeumgebung. Wer Testdaten plant, plant die Umgebung mit.
Was ist Testdatenmanagement?
Testdatenmanagement ist laut GTB-Lehrplan „die Menge aller methodischen, konzeptionellen, organisatorischen und technischen Maßnahmen und Verfahren zur Behandlung der Ressource Testdaten“ (GTB-Lehrplan TDS V1.1, 2021). Das Ziel nennt der Lehrplan gleich mit: die Testdaten „mit ihrem maximalen Nutzungspotenzial in den Testprozess einzubringen“.
Das ISTQB-Glossar V3.1 beschreibt TDM enger, als Prozess: „The process of analyzing test data requirements, designing test data structures, creating and maintaining test data.“ Der GTB-Lehrplan zitiert diese Fassung selbst. Die ISTQB-Fassung zählt die Tätigkeiten auf, die GTB-Fassung nimmt Organisation und Datenschutz dazu.
Was geht ohne TDM schief? „Schlechte“ Testdaten sind laut Lehrplan „fehlende, ungenaue, falsche, unzureichend verschlüsselte, duplizierte oder nicht zeitnah verfügbare Daten“, dazu sensible Informationen, die unverändert aus der Produktion kommen. Die GTB-Pressemitteilung von 2025 fasst es in einem Satz: „Ohne hochwertige Testdaten bleibt selbst der beste Testfall Stückwerk.“ (GTB-Pressemitteilung, 2025)
Welche Arten von Testdaten gibt es?
Der GTB-Lehrplan ordnet Testdaten auf zwei Achsen: nach ihrer Verwendung im Test und nach ihrer Herkunft. Nach Verwendung unterscheidet er Eingabe-, Zustands-, Ausgabe- und Soll-Daten. Nach Herkunft unterscheidet er synthetische Testdaten, Produktivdaten, anonymisierte und pseudonymisierte Daten und Mischformen (GTB-Lehrplan TDS V1.1, 2021).
Abbildung 2: Die vier Gewinnungsarten für Testdaten plus Mischform
Testdaten nach Verwendung
Art | Bedeutung | Beispiel aus dem Zahlungsverkehr |
|---|---|---|
Eingabedaten | Werte, die der Test an das Testobjekt übergibt | IBAN, Betrag und Valutadatum in der Überweisungsmaske |
Zustandsdaten | Datenbestand, der vor dem Test im System vorhanden sein muss | Konto mit Saldo 500 CHF und freigeschaltetem E-Banking |
Ausgabedaten | Daten, die das Testobjekt beim Test erzeugt | Buchungssatz, Bestätigungsseite, API-Antwort |
Soll-Daten | erwartetes Ergebnis, das Testorakel | Saldo nach der Buchung: 400 CHF |
Soll-Daten werden leicht vergessen. Ohne sie läuft ein automatisierter Test durch und prüft nichts. Das GTB fasst Testdaten in seiner Pressemitteilung knapp als „Eingabe, Zustand, Orakel“ zusammen (GTB-Pressemitteilung, 2025).
Testdaten nach Herkunft
Herkunft | Kennzeichen laut GTB | Worauf Sie achten |
|---|---|---|
Synthetische Testdaten | aus Metadaten erzeugt, „keinerlei inhaltlichen Bezug zu Produktivdaten“ | Qualität hängt an den Metainformationen; häufig in frühen Teststufen |
Produktivdaten (Produktionsabzug) | Kopie oder Teilabzug der Produktion | „problematisch, aber nicht zwangsweise unzulässig“; bei Teilabzügen referentielle Integrität halten |
Anonymisierte Daten | Personenbezug entfernt; formale, faktische oder absolute Anonymität | zu starke Anonymisierung macht Daten „wertlos“ |
Pseudonymisierte Daten | Kennungen ersetzt, Zuordnung über Zusatzwissen möglich | bleiben für den Verantwortlichen personenbezogene Daten (ErwG 26 DSGVO) |
Mischform | z. B. anonymisierter Bestand plus synthetische Ergänzungen | „In der Praxis hat sich häufig eine Mischform aus anonymisierten Testdaten und synthetischen Testdaten bewährt.“ |
Zu synthetischen Daten hält der Lehrplan fest: „Bei richtiger Anwendung bestehen keine regulatorischen Hinderungsgründe für den Einsatz synthetischer Testdaten.“ Eine Herstellerumfrage gibt einen Anhaltspunkt zur Verbreitung: Im World Quality Report 2025-26 von Capgemini, Sogeti und OpenText (Befragung 2025, mehr als 2000 Führungskräfte in 22 Ländern) erzeugen die befragten Organisationen im Schnitt 25 % ihrer Testdaten synthetisch (Sogeti, 2026).
Wie läuft der Testdatenmanagement-Prozess ab?
Der TDM-Prozess besteht laut GTB-Lehrplan aus 7 Aktivitäten, die von der Planung bis zur Archivierung der Testdaten reichen (GTB-Lehrplan TDS V1.1, 2021). Er läuft neben dem Testprozess her und liefert ihm die Daten zu:
Abbildung 3: Die 7 Aktivitäten des Testdatenmanagements nach GTB-Lehrplan
Planung (TDM): Bedarf, Aufwand, Termine und Zuständigkeiten festlegen. Ergebnis ist das Testdatenkonzept.
Steuerung (TDM): Fortschritt verfolgen und eingreifen, wenn Daten fehlen oder zu spät kommen.
Testdaten spezifizieren: aus den Testfällen ableiten, welche Daten in welcher Konstellation nötig sind.
Testdatenerzeugung konzipieren: je Datenbereich die Gewinnungsart wählen, ob synthetisch, Produktionsabzug, anonymisiert, pseudonymisiert oder gemischt.
Testdaten bereitstellen: die Daten in der richtigen Umgebung zum richtigen Zeitpunkt verfügbar machen.
Testdatenabschlussbericht erstellen: festhalten, welche Daten genutzt wurden und was offen blieb.
Testdaten archivieren: Bestände sichern, die für Nachtests oder Nachweise gebraucht werden.
Das wichtigste Ergebnis der Planung ist das Testdatenkonzept, laut Lehrplan „als Ergänzung bzw. Anlage zum Testkonzept“. Dazu nennt der Lehrplan weitere Arbeitsergebnisse, etwa eine Testdatenrichtlinie und einen Testdatenbereitstellungsplan.
Wer ist für Testdaten verantwortlich?
Der GTB-Lehrplan verteilt die Verantwortung für Testdaten auf 3 Rollen: Testdatenmanager, Testdatenmodellierer und Testdatenrealisierer (GTB-Lehrplan TDS V1.1, 2021).
Testdatenmanager: plant und steuert das Testdatenmanagement im Projekt.
Testdatenmodellierer: analysiert die Anforderungen an Testdaten und spezifiziert sie.
Testdatenrealisierer: arbeitet technisch, erzeugt die konkreten Testdaten oder stellt sie bereit.
Die drei Rollen dürfen bei derselben Person liegen. Der Lehrplan sagt dazu: „Sie können in der Realität in Personalunion besetzt werden.“ Gibt es keine eigenen TDM-Rollen, übernehmen Testmanager und Tester oder Entwickler diese Aufgaben. Jede Aufgabe braucht dabei eine namentlich zuständige Person.
Neben dem Testteam empfiehlt der Lehrplan, „Datenschutz, Recht und Compliance“ einzubeziehen. In einer Bank oder Versicherung heißt das: Die Datenschutzstelle sitzt schon bei der Planung am Tisch. Wer die Gewinnungsart festlegt, legt damit das Datenschutzrisiko der Testumgebung fest.
Was brauchen automatisierte Tests von Testdaten?
Automatisierte Tests brauchen Testdaten, die beim Start des Laufs vollständig vorhanden sind, ohne manuelle Beschaffung abrufbar sind und von keinem anderen Test verändert werden. Der GTB-Lehrplan nennt Stabilität als Kernanforderung an automatisierte Testläufe und begründet das knapp: „Sie finden häufig unbeaufsichtigt und/oder nachts statt.“ Um 2 Uhr nachts legt niemand einen verbrauchten Datensatz nach.
Abbildung 4: Drei Grundsätze für Testdaten in der Testautomatisierung (nach dora.dev)
Die Skripte zur Datenerzeugung und -bereitstellung „müssen zeitlich und inhaltlich mit den Skripten der Testautomatisierung abgestimmt sein“, und nicht mehr benötigte Datenbestände werden gelöscht (GTB-Lehrplan TDS V1.1, 2021).
Das DORA-Forschungsprogramm von Google (dora.dev) führt Testdatenmanagement als eigene Fähigkeit und setzt dafür 3 Grundsätze (dora.dev, 2026). Mit der EU-Verordnung DORA hat dieses Programm nichts zu tun.
„Adequate test data is available to run full automated test suites.“
„Test data for automated test suites can be acquired on demand.“
„Test data does not limit or constrain the automated tests that teams can run.“
dora.dev empfiehlt, dass Tests ihren Ausgangszustand wo möglich selbst über die APIs der Anwendung anlegen. Isolierte Testdaten nennt die Seite „a prerequisite for tests to run in parallel“. Als typische Fehler listet sie eine volle Kopie der Produktionsdatenbank, fehlende Maskierung sensibler Daten und veraltete Daten.
Vertiefungen zu den einzelnen Anforderungen:
Parameter und Datenzeilen trennen, damit ein Testfall viele Varianten abdeckt: datengetriebenes Testen Schritt für Schritt
Daten regelbasiert oder statistisch erzeugen und wissen, wann eine maskierte Kopie besser passt: Testdaten generieren und die passende Methode wählen
sensible Werte verfremden, ohne die Testbarkeit zu verlieren: Datenmaskierung für Testdaten
jedem Test eigene Daten geben, damit parallele Läufe nicht kollidieren: Checkliste zur Testdaten-Isolation
die Datenbereitstellung als festen Schritt in die Pipeline einbauen: Testautomatisierung in der CI/CD-Pipeline
Welche Regeln gelten für Testdaten in regulierten Branchen?
EU-Finanzunternehmen dürfen in Nichtproduktionsumgebungen nur „anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten“ speichern, so Art. 16(5) der Delegierten Verordnung (EU) 2024/1774 (EUR-Lex, 2024). Diese technischen Regulierungsstandards konkretisieren den Digital Operational Resilience Act, die Verordnung (EU) 2022/2554, die seit dem 17. Januar 2025 gilt. Gemeint ist hier die EU-Verordnung, nicht das Forschungsprogramm dora.dev.
Art. 16(6) erlaubt eine Ausnahme: Produktionsdaten dürfen nur für bestimmte Testanlässe und befristet in Testumgebungen liegen, mit Freigabe durch die zuständige Funktion und Meldung an die IKT-Risikomanagementfunktion. Für ein Testteam heißt das: Der Normalfall sind verfremdete Produktionsdaten. Die Ausnahme braucht eine Freigabe mit Ablaufdatum.
Regel und Alltag können auseinanderliegen. In einer Herstellerumfrage von Perforce (2026, mehr als 500 Führungskräfte aus Unternehmen) gaben 99 % an, Vorgaben zur Datenmaskierung zu haben, und 84 % lassen Ausnahmen davon zu (Perforce, 2026).
Für alle Branchen gilt die DSGVO: Pseudonymisierte Daten, die sich mit Zusatzinformationen einer Person zuordnen lassen, „sollten als Informationen über eine identifizierbare natürliche Person betrachtet werden“ (Erwägungsgrund 26, EUR-Lex, 2016). Was das für Produktivdaten im Test bedeutet, erklärt unser Beitrag zu DSGVO-konformen Testdaten.
In der Schweiz verlangt das FINMA-Rundschreiben 2023/1 von Banken und Wertpapierhäusern, Entwicklungs- und Testumgebung von der IKT-Produktionsumgebung zu trennen (FINMA-RS 2023/1, PDF, 2022). Für Versicherer gilt dieses Rundschreiben nicht. Seit dem 1. September 2023 ist das revidierte Datenschutzgesetz in Kraft (Fedlex, 2023). Welche Daten in Ihrer Testumgebung zulässig sind, lassen Sie mit Ihrer Datenschutzstelle prüfen.
Wie Banken Testautomatisierung unter diesen Vorgaben aufsetzen, zeigt der Beitrag zur Testautomatisierung in regulierten Banken. Wie Sie Test-, Abnahme- und Produktionsumgebung trennen und betreiben, steht im Leitfaden zur Testumgebung.
Wie messen Sie Testdatenmanagement?
Testdatenmanagement lässt sich mit 4 Kennzahlen messen: Zeitaufwand für Testdaten, Anteil verfügbarer Schlüsseldatensätze, Zahl der Tests ohne zusätzliche Datenbeschaffung und Testdatenkoeffizient. Die ersten drei stammen vom DORA-Forschungsprogramm von Google (dora.dev, 2026), der vierte aus dem GTB-Lehrplan.
Kennzahl | Quelle | Was sie zeigt |
|---|---|---|
Zeit für das Verwalten von Testdaten | dora.dev | wie viel Arbeit Beschaffung und Pflege kosten |
„percentage of key data sets that are available“ | dora.dev | ob die wichtigsten Datensätze bereitliegen |
„the number of automated tests that can be run without the need to acquire additional test data“ | dora.dev | wie weit die Automatisierung ohne Nachbeschaffung kommt |
Testdatenkoeffizient | GTB-Lehrplan TDS V1.1 | genutzte geteilt durch vorhandene Testdaten (20 GB von 100 GB = 20 %) |
Der Lehrplan führt den Testdatenkoeffizienten als Messgröße für Datenminimierung. Ein niedriger Wert zeigt Bestände, die Speicher und Risiko kosten und keinem Test dienen. dora.dev sieht das ähnlich und rät, die für automatisierte Tests nötige Datenmenge klein zu halten.
Womit fangen Sie an?
Bestand erfassen: Welche Umgebungen enthalten welche Daten, und woher stammen sie?
Bedarf spezifizieren: Eingabe-, Zustands- und Soll-Daten für die wichtigsten Testfälle.
Gewinnungsart festlegen je Datenbereich und im Testdatenkonzept festhalten.
Bereitstellung automatisieren, abgestimmt mit den Testskripten.
Messen und aufräumen: die vier Kennzahlen verfolgen, ungenutzte Bestände löschen.
Wo hilft Autemos beim Testdatenmanagement und wo nicht?
Autemos ist eine KI-gestützte Software für funktionale Testautomatisierung über Web, Mobile, API und Desktop. Autemos ist kein Werkzeug für Datenmaskierung oder Testdatengenerierung. Im TDM-Prozess unterstützt Autemos die Aktivität „Testdaten bereitstellen“ für automatisierte Testläufe. Es anonymisiert oder pseudonymisiert keine Produktivdaten, bildet keine Teilmengen aus Produktionsdatenbanken und gibt keine Rechtsberatung.
In Autemos legen Sie Datasets an, bearbeiten oder importieren sie (CSV, XLSX, JSON) und nutzen sie in mehreren Test-Workflows, etwa für Login-Benutzer, Produktlisten oder Testbestellungen. Externe Quellen lassen sich anbinden: REST-APIs, JSON-Dateien, Excel, Datenbanken oder die Datenquelle iSynth. Runtime Bindings laden die Daten erst zur Laufzeit und geben sie als Variablen an den Test.
Für parallele Läufe markiert die Funktion One-Time Use verbrauchte Voucher, Registrierungen, Tokens oder Testbenutzer, damit sie kein zweites Mal ausgegeben werden. Scopes auf Ebene RUN, PROJECT oder TENANT legen den Geltungsbereich eines Datensatzes fest, und Bindings lassen sich pro Umgebung (DEV, TEST, STAGING, PROD) trennen. Die Produktseite zu Test Data Handling in Autemos beschreibt das Problem so: „Verbrauchte Voucher, doppelte Benutzer, abgelaufene Tokens oder leere Datasets führen zu Fehlern, die nichts mit der Applikation zu tun haben.“
TDM-Aufgabe | Autemos | Was Sie dafür brauchen |
|---|---|---|
Testdaten für automatisierte Läufe bereitstellen | Ja: Datasets, externe Quellen, Runtime Bindings | ein Testdatenkonzept, das festlegt, welche Daten wohin gehören |
Einmal-Daten in parallelen Läufen schützen | Ja: One-Time Use | eine Liste der Daten, die nach einmaligem Gebrauch verbraucht sind |
Daten pro Umgebung trennen | Ja: Bindings pro Umgebung | getrennte Umgebungen auf Infrastrukturebene |
Produktivdaten maskieren, anonymisieren oder pseudonymisieren | Nein | ein Maskierungs- oder TDM-Werkzeug |
Synthetische Testdaten erzeugen | Nein, Autemos kann eine Quelle wie iSynth anbinden | einen Generator oder eigene Skripte |
Teilmengen aus Produktionsdatenbanken bilden | Nein | ein Subsetting-Werkzeug |
Rechtliche Bewertung | Nein | Datenschutzstelle und Rechtsabteilung |
Häufig gestellte Fragen
Was ist der Unterschied zwischen Testdaten und Testdatenmanagement?
Testdaten sind die konkreten Werte, die ein Test braucht; Testdatenmanagement ist die Planung, Gewinnung, Bereitstellung und Pflege dieser Werte. Das ISTQB-Glossar definiert Testdaten als „Data needed for test execution.“
Darf man Produktivdaten zum Testen verwenden?
Produktivdaten im Test sind nur unter Auflagen möglich. Ein Produktionsabzug ist laut GTB-Lehrplan „aus datenschutzrechtlichen Gründen problematisch, aber nicht zwangsweise unzulässig“. EU-Finanzunternehmen dürfen in Nichtproduktionsumgebungen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten speichern (DORA-RTS Art. 16(5)), mit befristeten, freigegebenen Ausnahmen nach Art. 16(6).
Sind pseudonymisierte Testdaten noch personenbezogen?
Ja, pseudonymisierte Testdaten bleiben nach Erwägungsgrund 26 DSGVO personenbezogen, solange sie sich mit Zusatzinformationen einer Person zuordnen lassen. Nur anonyme Informationen fallen aus dem Datenschutzrecht heraus. Die Pflichten aus der DSGVO gelten damit weiter, auch in der Testumgebung.
Was ist ein Testdatenkonzept?
Ein Testdatenkonzept ist das Planungsdokument des Testdatenmanagements, laut GTB-Lehrplan „als Ergänzung bzw. Anlage zum Testkonzept“. Es legt fest, welche Daten pro Teststufe gebraucht werden, wie sie gewonnen und bereitgestellt werden, wer zuständig ist und wie die Daten geschützt, archiviert oder gelöscht werden.
Braucht ein kleines Team eigene TDM-Rollen?
Nein, die drei TDM-Rollen dürfen laut GTB-Lehrplan in Personalunion besetzt werden. Ohne eigene Rollen übernehmen Testmanager und Tester oder Entwickler die Aufgaben von Testdatenmanager, Testdatenmodellierer und Testdatenrealisierer. Jede Aufgabe braucht dabei eine namentlich zuständige Person.
Fazit
Testdatenmanagement braucht einen Plan, bevor der erste Test läuft. Der GTB-Lehrplan Test Data Specialist liefert die Struktur: 4 Arten nach Verwendung, 4 Gewinnungsarten plus Mischform, 7 Aktivitäten und 3 Rollen, festgehalten im Testdatenkonzept. Für automatisierte Tests ergänzt das DORA-Forschungsprogramm von Google (dora.dev) 3 Grundsätze: genug Daten, auf Abruf, ohne Einschränkung für die Tests. EU-Finanzunternehmen müssen Art. 16(5) der EU-DORA-RTS 2024/1774 einhalten, Schweizer Banken die Umgebungstrennung nach FINMA-Rundschreiben 2023/1. Ein guter erster Schritt ist eine Bestandsaufnahme: welche Daten wo liegen, woher sie stammen und welcher Test sie nutzt. Wenn Sie sehen möchten, wie Datasets, Runtime Bindings und One-Time Use in Ihren eigenen Testläufen aussehen, vereinbaren Sie ein Gespräch mit unserem Team.
