Testdatenmanagement - Heilmittel oder Hype?

Ihr kennt es sicherlich: Je einfacher Außenstehenden ein gewisses Gebiet erscheint, desto größer sind die Erwartungen an mögliche Lösungen. Besonders ausgeprägt erlebe ich das im Testdatenmanagement. In meinem Blog-Beitrag zeige ich euch, was es mit dem Thema auf sich hat, welche Fehler häufig gemacht werden und wie ihr diese vermeiden könnt.

Zunächst möchte ich allerdings einen kleinen Exkurs machen und kurz erklären, was man unter Testdatenmanagement überhaupt versteht: Testdaten werden in jedem Softwareentwicklungsprojekt benötigt. Das Testdatenmanagement gewährleistet durch die Trennung von Testfallerstellung, -durchführung und Testdatenpflege die Konsistenz und gleichbleibende Qualität der verwendeten Testdaten über alle Testaktivitäten hinweg. Auf diese Weise wird die Effizienz sowie Aussagekraft der Testmaßnahmen und damit zeitgleich die Qualität der getesteten Prozesse und Systeme gesteigert.

Meine Rolle als Testdatenmanager

Seit zwei Jahren unterstütze ich einen großen Versicherer in voneinander unabhängigen Projekten beim Modellieren, Erzeugen und Bereitstellen von Testdaten. Dieser Versicherer hat nun extra eine strategische Einheit gegründet, um den gesamten Konzern beim Testen von Software methodisch zu unterstützen. Die Abteilung, in der ich arbeite, berät und unterstützt dazu gleichermaßen Linienfunktionen und strategisch wichtige Sonderprojekte bei Fragen rund ums Testdatenmanagement. Dazu gehören unter anderem die methodische und fachliche Beratung - etwa zur DSGVO-konformen Anonymisierung personenbezogener Daten und der Betrieb und Support von Tools zum Erstellen und Transportieren von Testdaten. Mit der Systematisierung und dem Einsatz solcher zentralen Tools wollen wir Kannibalisierungseffekte, Datenwildwuchs und Verwaltungsaufwände reduzieren, die entstehen, wenn mehrere Projekte auf dieselben Testumgebungen und -daten zugreifen.

Testdaten sind von enormer Bedeutung für den Softwaretest, werden aber oft nicht verstanden und darum vernachlässigt. Umso glücklicher bin ich, dass mein Kunde die Relevanz erkannt hat und ich hier an strategischen Grundsatzentscheidungen mitwirken kann. Somit erledige ich für meinen Kunden streng genommen zwei Aufgaben: Eine meiner Hauptaufgaben besteht darin, verbindliche Richtlinien für den Umgang mit Testdaten zu erarbeiten sowie Best Practices zu identifizieren, diese aufzubereiten und im Konzern zu etablieren. Operativ unterstütze ich zudem ein strategisch wichtiges Großprojekt – Vollzeit und in Personalunion als Testdatenmanager, -modellierer und -erzeuger.

Der ständige Austausch auf der Projektfläche hilft mir in diesem Projekt mehr dabei, Risiken und Hintergründe besser zu erkennen, als ein unpersönliches Gruppenpostfach. Meine Kolleginnen und Kollegen haben in mir einen proaktiven Partner, der im selben Boot sitzt und skalierbare, aber pragmatische Lösungen für Probleme sucht, die ihn unmittelbar selbst betreffen. Das erhöht die Akzeptanz immens.

Noch fehlen uns die Ressourcen, um neben dem Tagesgeschäft jedes Projekt personell zu begleiten. Daher bieten wir einen Teil unserer Leistungen bislang nur im Rahmen von Pilotprojekten an - sie müssen aber nicht vom ganzen Konzern genutzt werden.

Der theoretische Ansatz

In unserem Team sehen wir eine frühe Systematisierung der Modellierung, Anforderung und Bereitstellung von Testdaten vor – wissentlich, dass nur die wenigsten Anforderungen an Testdaten bereits vor dem ersten bilateralen Teilintegrationstest bekannt sind.

Es ist ein verbreiteter Trugschluss, dass die Identifizierung der benötigten Testdaten erst dann möglich und sinnvoll ist, wenn die Entwicklung abgeschlossen ist. Im Gegenteil: Je später man die Anforderungen an Testdaten erhält, desto schwieriger wird es, diese noch in ein Gesamtkonzept zu integrieren und die Daten überhaupt bereitzustellen. Daher ist es aus meiner Sicht wichtig, von Beginn an zu verdeutlichen, dass man als Testdatenmager nur methodisch unterstützen kann. Für fachliche Modellierungen müssen die jeweiligen Product Owner und Wissensträger früh in die Verantwortung genommen werden.

Die praktische Umsetzung

Mein praktisches Vorgehen als Testdatenmager sieht folgendermaßen aus: In den ersten Projektphasen unterstütze ich meine Kolleginnen und Kollegen dadurch, dass ich kritische Fragen stelle, Annahmen treffe und mir einzelne „Verbündete“ suche, mit denen ich einfache Modelle verprobe und die erfolgreichen inkrementell skaliere.

Je nach Testphase beleuchten wir mit diesen Modellen beispielsweise Fragen zu Datenflüssen sowie zur referentiellen Integrität über Systemgrenzen hinaus oder wir pilotieren komplexe Datenkonstrukte für einen technischen Durchstich, bevor wir in den Rollout gehen.

Im Idealfall wird zu Beginn eines Projekts ein einheitliches Verständnis über die Testdatenstrukturen erarbeitet, wodurch wir Wissensträger identifizieren und in die konkrete Ausarbeitung einsteigen können. Arbeitet das Team von Beginn an übergreifend zusammen, verbessert das die Testdatenbereitstellung enorm.

Wenn im Projekt allgemein von „Testdaten“ die Rede ist, kann (leider) vieles gemeint sein, etwa Testdatenobjekte wie Versicherungsagenturen oder Provisionssätze, die jeweils unterschiedliche Attribute haben (zum Beispiel „Agenturinhaber“ oder „Abschlussprovision“). Diese Attribute haben wiederum mehrere Ausprägungen – eine „Abschlussprovision“ weist zum Beispiel je nach Versicherungssparte unterschiedliche Ausprägungen prozentualer Werte aus. Meiner Erfahrung nach meinen die Kolleginnen und Kollegen mit dem Begriff „Testdaten“ meist mehrere, ganz konkrete Ausprägungen eines Testdatenobjekts.

Um dann alle wieder in ein Boot zu holen und eine gemeinsame Sprache zu etablieren, hat sich für mich folgende Unterteilung von bewährt:

• Ein- und Ausgabedaten
• Stamm- und Bewegungsdaten
• Basisdaten (beispielsweise benötigt jedes Neugeschäft zumindest auszugsweise Tarif-, Vermittler- und Provisionsdaten, auch wenn diese nicht im Fokus des Testfalls stehen)
• Konfigurationsdaten (etwa Test User und Berechtigungen)
• Umgebungsdaten (zum Beispiel Softwareversionen)
• Metadaten (sie beschreiben Testdaten näher - etwa zur Versionierung)

Eins ist klar: Wenn niemand darauf drängt, befassen sich Projekte meist zu spät mit Testdaten. Es stehen eher die konkreten und fachlichen Ausprägungen im Fokus, als die abstrakten, technischen Objekte. Wenn aber die Tools zur Bereitstellung der technischen Objekte fehlen oder nur Teile bereitgestellt werden können, kann das schwerwiegende Folgen haben - vom kostspieligen Nachrüsten und geplatzten Lieferterminen über eine ungenügende Softwarequalität bis zu unzufriedenen Kundinnen und Kunden oder Vertragsstrafen. Häufig ergibt sich daraus folgendes Problem: Das Management hat vielleicht mal davon gehört, dass es irgendein Tool gibt, befasst sich aber dann nicht damit, was das Tool nicht abdeckt und welche manuellen Aufwände daher noch zusätzlich eingeplant werden müssen. Verwendet ihr hingegen das passende Testdatenmanagementtool, kann die Effizienz der Testdatenversorgung enorm gesteigert werden. An dieser Stelle ist jedoch Vorsicht geboten, denn allein die Toolauswahl und das notwendige Mapping der Datenfelder können mitunter mehr Zeit in Anspruch nehmen, als das eigentliche Projekt. Mein Tipp: Identifiziert frühzeitig die zu liefernden Objekte, lernt die Bereitstellungsprozesse kennen und prüft, ob ihr nicht doch mit Bordmitteln auskommt.

Testdatenmanagement ist für uns alle Neuland oder?

Wenn ich Tester frage, welche Testdaten sie benötigen, höre ich regelmäßig „mein Testfall soll einfach nur durchlaufen.“ Dann frage ich nach:

• Was sollen die Daten denn „können“?
• Wann, wo und wie lange braucht ihr die Daten?
• Sollen die Daten wieder in ihren Ursprungszustand zurückversetzt werden (falls ja, welche Systeme sind noch betroffen)?

Jede Antwort auf eine dieser Fragen wirft wiederum weitere und kritische Fragen auf: Wenn klar ist, was die Daten fachlich können sollen, muss immer noch geklärt werden, wie das Ganze technisch umgesetzt wird. Selbst die Suche nach einem einzelnen, schützenspflichtigen Attribut wie „Vorname“, das in unzähligen Anwendungen und Code-Tabellen vorkommt und dort unterschiedlich verfremdet wird, entwickelt sich dann schnell zum (zeitraubenden) Abenteuer.

Testdaten können euch herausfordern, egal, in welcher Rolle ihr tätig seid: Wenn Testdaten von den Testdurchführenden nur als einfache, operative Eingabedaten verstanden werden und User nicht beachten, welche Prozesse und Prüfungen sie mit der Eingabe im Hintergrund auslösen, entstehen schnell Probleme. Die Ursache dieser Probleme sind dann nur selten richtige Softwarefehler, sondern oft sogenannte „Abweichungen“ vom erwarteten Ergebnis. Das bedeutet, dass die Software wie vorgesehen funktioniert, dass das tatsächliche Ergebnis wegen falscher Benutzung aber vom erwarteten Ergebnis abweicht. Ein gutes Testdatenmanagement reduziert das Auftreten solcher Abweichungen.

Meiner Erfahrung nach können aber auch viele Testfalldesigner ihre Anforderungen alleine nicht ausreichend artikulieren. Neben mangelnder Systemkenntnis fehlt oft auch das Verständnis dafür, was Testdaten überhaupt sind und welche Bedeutung das für ihre Verwendung hat. Daher ist die Bereitstellung von Testdaten längst keine einfache Migrationsaufgabe mehr - und war es auch nie. Es geht nicht bloß um die Frage, ob ein produktiver Teilabzug zum Testen ausreicht oder ob Daten synthetisch angereichert werden müssen. Die kritischen Fragen fokussieren weder technische noch fachliche Tests, sondern das Sicherstellen der Datenintegrität über komplexe Anwendungslandschaften, die kostensensitive Verwaltung von Testdaten, das Einhalten gesetzlicher Vorgaben und den Schutz vertraulicher Kundendaten:

• Wer (im Projekt/Konzern) darf die Daten sehen und nutzen?
• Wie wird der Datenteil, der geschützt werden muss, korrekt anonymisiert?
• Wie kann die Revisionsfähigkeit gesichert werden?

Holt euch Hilfe

Während sich Fachbereiche noch gut mit den eigenen Systemen auskennen, stehen besonders externe Projektmitarbeitende vor der Herausforderung, sich regelmäßig auf unbekannte IT-Systeme einzustellen. Dass sich Tester dann darauf beschränken „den Testfall durchzubekommen“ und bewährte Testdatenkombinationen verwenden, ist zwar nachvollziehbar, aber auch gefährlich. Ich habe mehrfach erlebt, dass Testdaten solange ohne Freigabe mitbenutzt wurden, bis sie nicht mehr „funktionierten“ und niemand wusste, warum. Es treten dann vermehrt (unechte) Abweichungen auf. Das hat zur Folge, dass teure Spezialisten aufwendig analysieren müssen, ob es sich bei den gemeldeten Abweichungen um Programmierungs-, Konzeptions-, oder Anwenderfehler handelt, statt sich auf die Korrektur echter, kritischer Fehler zu konzentrieren.

Um das zu umgehen, empfehle ich euch: Sprecht – und zwar grade im Projektgeschäft – über eure konkreten Bedürfnisse, Annahmen und Erwartungen und setzt euch mit Methoden und Prozessen der Testdatenbereitstellung auseinander. Jeder kann mit sehr geringem Aufwand lernen, wie man sich selbst und anderen viel Zeit und Nerven spart. Ich kann daher jedem Unternehmen nur empfehlen, sich von Anfang an für ein systematisches Testdatenmanagement zu entscheiden, um unnötige Aufwände bei Defect Managern, Analysten, Entwicklern und Architekten zu vermeiden.

Ihr möchtet mehr zu spannenden Themen aus dem Versicherungsbereich erfahren, dann werft einen Blick auf die bisher erschienenen Blog-Beiträge.

Wenn ihr wissen möchtet, mit welchen Themen wir aktuell im Versicherungsbereich unterwegs sind, besucht unsere Website.