DevOps / Software-Entwicklung / Software-Test / Testautomatisierung / Testmanagement

Testdatenmanagement als Treiber für effizientere Software-Tests

Mehr Qualität braucht das Land! Hohe Testabdeckung bei gleichzeitiger Reduktion der Anzahl der Testfälle wird mehr und mehr zum Basisanspruch im Softwaretest. Getrieben von diesem Wunsch, aber auch von der Novelle der EU-Datenschutzrichtlinie, sind sowohl das Testdatenmanagement als auch die toolgestützte Testdatenerzeugung in den letzten Jahren vom Stiefkind zum Fokusbereich der Branche avanciert.

Energiesparlampe_Glühbirne_Visual

In seinem Artikel „Testdatenmanagement – Der richtige Input für ihre Tests!“ führte mein Kollege Maximilian Wallisch aus, weshalb Testdatenmanagement ein Prozess ist, der im Idealfall den gesamten Ablauf eines IT-Projekts begleitet, wer davon profitiert und welche Schritte es zur professionellen Implementierung im Entwicklungsprozess braucht.

Das Thema Testdatenmanagement (TDM) wird sowohl im Test- als auch im Entwicklungsbereich angesichts Agile und DevOps immer wichtiger. Dies führt dazu, dass die meisten großen Toolhersteller im Bereich Testautomatisierung mittlerweile TDM Tools anbieten. Weiters steht eine Gesetzesnovelle im EU-Datenschutzrecht vor der Tür. In Zukunft hat jedes Unternehmen dafür Sorge zu tragen eingesetzte Personendaten zu verfremden. Das bedeutet, dass der Einsatz von Produktivdaten in nicht-produktiven Bereichen erschwert wird. Testdaten und Daten in der Entwicklung sind hiervon nicht ausgenommen.

Grund genug, um uns tiefer in das Thema Testdatenmanagement vorzuwagen. In zwei Artikeln betrachten wir den IST-Stand und werden diesen mit der Idee von professionellem Testdatenmanagements vergleichen. Gezielt wollen wir dabei auf folgende Fragestellungen eingehen:

  • Welche Anforderung haben Testdaten zu erfüllen?
  • Wie maximiert man die Qualität von Testdaten?
  • Was hat es mit der neuen Datenschutzrichtlinie, von der jeder spricht, auf sich?
  • Welche erweiterten Benefits kann man aus professionellem TDM ziehen?
  • Und zu guter Letzt: Warum sollte man sich ein Tool für Testdatenmanagement leisten, wo man doch bisher auch ohne ausgekommen ist?

Oder anders ausgedrückt: Wir wollen dem Thema Testdatenmanagement noch einmal so richtig auf den Zahn fühlen!

 

Alltagsg‘schichten aus der Testabteilung

Aus dem Umfeld der Tester und Entwickler erfahren wir immer wieder, dass Testdaten in Projekten häufig auf „historisch gewachsene“ Art und Weise generiert und verwaltet werden. Dies bedeutet oftmals, dass Tester und Entwickler in einer eigenen Datenbank ihre Daten so konstruieren, wie sie für Testfälle gebraucht werden und diese Testdaten immer wieder verändern und anpassen. Es kann auch bedeuten, dass ein definierter Datenbestand (z.B. ein Abzug von Produktivdaten [Golden Copy]) in der Testumgebung eingespielt, und von jedem Entwickler und Tester verwendet wird. Die Testdaten werden dabei individuell so verändert, wie sie gerade für den jeweiligen Testfall benötigt werden. Es gibt keine Versionierung der Testdaten, gleiche Testfälle werden oft mit verschiedenen Datensets getestet, die Daten in der Datenbank werden verändert und „angepasst“ bis die Datenkonsistenz in Mitleidenschaft gerät und Testfälle fehlschlagen. Das ist oft der Zeitpunkt an dem eine neue Golden Copy eingespielt wird und der ganze Prozess von vorne beginnt. Der Mann von La Mancha lässt grüßen.

Daten herzurichten ist ein langwieriger Prozess, der zumeist viel Zeit in Anspruch nimmt. Oft können Testdaten nicht einfach über die GUI hergestellt werden, sondern benötigen (aufwendige) Datenbanktransaktionen. In diesem Prozess ist man häufig von anderen Personen, Systemen, Projekten, Drittanbietern, etc. abhängig, die nicht jederzeit verfügbar sind, wodurch sich der gesamte Entwicklungsprozess verzögert. Ohne Speicher-, Erfassungs- und Versionierungsmaßnahmen wird man diesen Prozess immer wieder durchlaufen und an diesen Prozess immer wieder Produktivität verlieren.

Das ist der Hauptgrund weshalb – besonders in den letzten Jahren – Testdatenmanagement vom Stiefkind der Entwicklung zu einem der Fokusbereiche wurde. Wir sehen also, dass die Handhabung von Testdaten ohne professionelles Testdatenmanagement sehr zeitraubend, und damit auch kostenintensiv, sein kann.

Ein genauso großes Problem ist aber, dass der Best Practice Ansatz nur selten wirklich gute Testdaten entstehen lässt.

 

Was sind „gute“ Testdaten?

Beim Testen von Software im Allgemeinen und bei automatisierten Tests im Speziellen müssen im Vorfeld der einzelnen Tests immer wieder spezifische Vorbedingungen hergestellt werden. Dazu gehört, dass auf der Testumgebung bestimmte Einstellungen vorgenommen werden (z.B. Sprache festlegen, Datum und Uhrzeit ändern, Softwareversion einspielen, etc.), aber auch, dass die Datenbank bzw. die Testdaten für den jeweiligen Testfall in den jeweils benötigten Zustand gebracht werden. So selbstverständlich der erste Schritt im Softwaretest meist sein mag, so ungläubig reagieren viele, dass Zustandsbereinigung der Testdaten kein Fremdwort sein sollte.

Man möchte möglichst realistische Daten für Tests haben und tendiert zur Auffassung, dass die realistischsten Daten immer jene sind, die auch in der Produktion verwendet werden. Viele Unternehmen verwenden daher eine Golden Copy der Produktivdaten als Testdaten. Wenn das nicht möglich ist, müssen sich Entwickler und Tester eigene Testdaten generieren, die zumeist auch an Produktivdaten angelehnt sind. Meist gibt es keine Synergien zwischen individuell verwendeten Daten, oftmals fehlt die Kommunikation zwischen Abteilungen, die Daten sind nicht transparent und für alle zugreifbar abgelegt. Viel Arbeitszeit geht in all diesen Fällen durch das Erschaffen und Adaptieren von Testdaten verloren, obwohl diese eigentlich produktiv genutzt werden könnte (auf die Vorteile von TDM im DevOps-Prozess, mit dem Ziel die Kommunikation zu erhöhen kommen wir noch später im Detail zu sprechen).

Wir erleben diesen Ansatz tagtäglich bei unseren Kunden: das System läuft, die Daten sind vorhanden, die Testfälle laufen. Oberflächlich betrachtet sieht alles schön und gut aus.

Allerdings muss man bereits an dieser Stelle aufpassen: Es stimmt zwar, dass durch Produktivdaten im Test eine große Anzahl der im täglichen Betrieb anfallenden Fälle getestet werden. Es ist aber ein Trugschluss zu glauben, dass durch die Verwendung von 99%, der im Produktivbetrieb anfallenden Daten auch tatsächlich 99% der Fehlerquellen abgedeckt werden. Besonders Negativtestfälle und Grenzwertanalyse werden durch solche Testfälle geradezu sträflich vernachlässigt.

Im professionellen Testbetrieb sollte durch Äquivalenzklassenbildung eine sinnvolle Gliederung der Tests in verschiedene Kategorien erfolgen. Um diese Tests auch beliebig oft durchführen zu können ist ein Abzug von Produktivdaten meist zu wenig, da gerade Datensets im Grenzwertbereich meist rar gesät sind. Nun ist die erste Situation erreicht, in der professionelles Testdatenmanagement den häufigen Best Practice Ansatz aussticht.

Mit dem Hinzufügen von synthetischen Testdaten zu den Produktivdaten, wird eine höhere bzw. dichtere Testabdeckung bei gleichzeitiger Reduktion der benötigten Testdurchläufe erzielt. Wie wir in weiterer Folge sehen werden, weisen synthetische Testdaten dieselbe Qualität wie Produktivdaten auf und können diese oft sogar noch verbessern.

 

Synthetische Daten können BESSER sein als Produktivdaten? Wie soll denn das gehen?

Ganz einfach: Testdaten können verbraucht werden. Das führt oft zu Problemen, denn einer der wichtigsten Aspekte im Softwaretest ist die Reproduzierbarkeit von Ergebnissen. Denken wir nur an einen etwas komplexeren Testfall: Es werden Testdaten verwendet, die im Hintergrund in der Datenbank durch Verknüpfung mehrerer Tabellen entstehen. Vordergründig fällt diese „Background-Magic“ nicht auf, und im Moment des Tests ist sie auch nicht weiter relevant.

Durch den Test werden Parameter des Datensets so geändert, dass die Testdaten bei einem weiteren Testlauf nicht mehr verwendet werden können (z.B. indem ein Grenzwert überschritten oder ein Datensatz gelöscht wird). Der Testfall startet, der Point of no Return für den Datensatz ist erreicht, der Testfall läuft weiter, aber der Testfall scheitert etwas später an unvermuteter Stelle mit einer bis dato unbekannten Fehlermeldung.

Die Testdaten sind nun so nicht mehr vorhanden, aber der Fehler muss rasch behoben werden da die Deadline im Nacken sitzt. Zu diesem Zeitpunkt wünscht man sich nichts sehnlicher, als auf Knopfdruck valide Testdaten mit denselben Parametern nochmal generieren zu können. Natürlich ist es möglich ohne TDM wieder einen Datensatz zu finden, der denselben Fehler auslöst oder den Fehler auf andere Art zu reproduzieren. Allerdings weiß jeder, der selbst schon einmal in dieser Situation war, dass dies einen enormen zeitlichen Mehraufwand bedeutet. Und da Zeit bekanntlich Geld ist, hätte man sich mit professionellem Testdatenmanagement an dieser Stelle Einiges ersparen können.

(Gute) Synthetische Testdaten sind darauf ausgelegt maximal reproduzierbar zu sein, und mit möglichst wenig versteckten Abhängigkeiten in der Datenbank auszukommen. Die Reproduzierbarkeit ist ebenso beim Verbrauch von Testdaten gegeben: Da die Schlüsselparameter für jeden erzeugten Datensatz vorgegeben sind, wird jeder neu erzeugte Datensatz mit denselben Eigenschaften ins Rennen geschickt. Andernfalls langwieriges Debugging wird dadurch zu einer Sache von wenigen Minuten. Gerade bei der Testautomatisierung in der Software- oder Test-Entwicklung, wo in kurzer Zeit viele Testdurchläufe erfolgen und somit große Mengen an Daten verbraucht werden, bietet das einen unschätzbaren Mehrwert.

 

Testdaten können nicht nur verbraucht werden, sie können auch veraltet sein

Derselbe Aspekt zwischen Produktivdaten und synthetischen Daten ist auch bei der Datenalterung zu beachten. Oder anders ausgedrückt: Ein veralteter Datensatz ist genauso nutzlos wie ein Fehlender.

Testfälle können spezifische Daten oder Uhrzeiten benötigen, um das gewünschte Ergebnis zu liefern. Ein Datenset muss möglicherweise in der Zukunft oder eine spezifische Anzahl an Tagen in der Vergangenheit liegen um spezielle Konstellationen der Testumgebung testen zu können. Da der Abzug und das Einspielen von Produktionsdaten auf der Testumgebung oft einen erheblichen Mehraufwand bedeuten, müssen Tester und Entwickler längere Zeit mit demselben Datenstand vorliebnehmen. Mit der steten Verwendung von beispielsweise in der Zukunft liegenden Testdaten, werden die verfügbaren Testdaten mit jedem Tag weniger, bis schließlich keine Daten mehr zum Testen vorhanden sind. In dem Fall kann man mühsam per Hand neue Datensätze einspielen, den Mehraufwand einer neuerlichen Golden Copy in Kauf nehmen – sofern das gerade möglich ist – oder man bedient sich eines professionellen Testdatenmanagements: Die benötigten Daten werden zeitgerecht erzeugt, weisen die benötigten Parameter auf, sowohl Entwickler als auch Tester sparen Nerven. Zusätzlich werden wieder Zeit und Geld gespart!

testdatenmanagement

Synthetische Testdaten machen das Leben einfacher!

Nehmen wir als Beispiel eine Transaktion, die an Feiertagen anders ablaufen soll, als während des restlichen Jahres. Der Anspruch an den Datensatz ist klar: Entweder es ist ein Feiertag oder nicht. Keine Background Magic, keine veralteten Daten, keine verbrauchten Daten.

Als Schüler habe ich die Zeit zwischen den Heiligen Drei Königen (06.01.) und Karfreitag (meist im April) gehasst – kein einziger Feiertag! Jetzt als Tester geht es mir ähnlich. Gerade beim Debuggen muss man kurz vor Ostern in Datenbanken oft sehr weit nach hinten graben, um einen Datensatz zu finden, der den Anspruch erfüllt ein Feiertag zu sein. Wenn man dann noch andere Sonderbedingungen hat – beispielsweise ein Tag der Feiertag ist UND an ein Wochenende fällt – wird das Scrollen schon mal zur Fleißaufgabe.

Werde solche Testdaten synthetisch erzeugen, kann man dabei mehrere Fliegen mit einer Klappe schlagen:

  • Gerade im oben angeführten Beispiel spart man sich Flüchtigkeitsfehler („Ach, das war doch kein Sonntag??“)
  • Man hat das richtige Datenset in Kürze zur Hand – jederzeit, auch bei der x-ten Iteration
  • Es gibt noch viel komplexere Strukturen als Feiertage die auf ein Wochenende fallen. Solche sind in Produktivdaten einfach nicht zu jedem Zeitpunkt vorhanden.

 

Synthetische Daten klingen irgendwie „falsch“ – sie sind es aber nicht!

Das Wort alleine klingt schon irgendwie negativ behaftet: „synthetisch“. Man denkt an synthetische Produkte, Aromen, Nahrung. Das kann für meine Testumgebung ja gar nicht gesund sein! Oder etwa doch?

Synthetische Daten ist ein Kunstbegriff, der vieles bedeuten kann. Sie sind nicht per se gut oder schlecht. Wie so oft im Leben kommt es auf die Situation und die richtige Handhabung an. Es ist im Softwaretest kaum möglich auf Produktivdaten zu verzichten. Produktivdaten haben gegenüber gänzlich künstlich geschaffenen Daten viele Vorteile. Der wohl wichtigste Vorteil zu allererst: Es gibt sie schon! Produktivdaten sind im Normalfall schon vorhanden, dazu meist in relativ hohem Volumen bei gleichzeitig hoher Konsistenz. Noch dazu werden mit Produktivdaten große Teile der Funktionalität abgedeckt. Durch diese Vorteile nimmt man auch die gelegentlichen Inkonsistenzen und den beigemengten „Datenmüll“ auf sich.

An dieser Stelle kommt die Synthese ins Spiel. Fehlende Testdaten werden mittels vorhandener Daten interpoliert. Als Beispiel nehmen wir ein beliebiges Intranet-Portal. Für den Negativtest benötigen wir einen Benutzer mit gültigem Vor- und Nachnamen sowie Wohnort, der am 30. Februar Geburtstag hat (für dieses Beispiel nehmen wir an, dass in Portal und Datenbank das Geburtsdatum als String gespeichert wird). So einen User werden wir in den Produktivdaten (hoffentlich) nicht finden. Um Testziel, Lesbarkeit, Wartbarkeit und einen realistischen Bezug der Testdaten nicht zu gefährden, sollte man einen komplett zufällig generierten Namen oder Wohnort tunlichst vermeiden (besonders bei Orten wäre ein „Reality-Check“ des Portals denkbar – nur echte Ortsnamen können verwendet werden).

Im professionellen Testdatenmanagement werden die Testdaten aus einer Datenbank generiert, in der reale Vornamen, beliebige Nachnamen und gültige Wohnorte hinterlegt sind (gerade professionelle Tools bieten solch eine Funktion häufig standardmäßig an). In Sekundenschnelle können wir selbst bei tausenden Testdurchläufen immer neue, gültige Kombinationen aus Vornamen, Nachnamen und Wohnort erzeugen. Dadurch ist die Validität des Tests gewährleistet (es soll ja das Geburtsdatum und nicht der Name oder Ort getestet werden!), und nebenbei befüllen wir die eigene Testumgebung mit sinnvollen, differenzierbaren und vor allem gültigen Daten, und nicht mit „Max Mustermännern“ oder „Lfzygmß Olürps“.

(Hinweis: Wenn man die Namensfelder testen würde, wäre es wünschenswert auch ungültige, z.B. zufällig generierte Namen wie im obigen Beispiel zu verwenden – Stichwort: Fuzzing. Eventuell könnte man sogar mit Zahlen oder Sonderzeichen testen. Da wir in dem Beispiel aber explizit nur das Feld Geburtsdatum testen wollen, dürfen wir hier das Testziel nicht aus den Augen verlieren!)

Wie synthetische Daten im Rahmen der neuen EU-Datenschutzrichtlinie behilflich sein können, werde ich in meinem nächsten Artikel noch genauer erörtern.

Wir haben gesehen, die Qualität von Testdaten ist imperativ für mehrere Dinge:

  • Testabdeckung
  • Verfügbarkeit von benötigten Daten
  • Reproduzierbarkeit von Ergebnissen

Oder simpel ausgedrückt: Die Qualität der Testdaten entscheidet über die Qualität der Tests!

 

Die Testdaten sind synthetisiert. Und was jetzt?

Der Schritt zur Verbesserung und Professionalisierung der Testdaten ist zwar ein wichtiger, aber doch nur einer von mehreren. Aber keine Sorge: Ist der erste Schritt erst gewagt, fallen die Folgenden schon viel leichter!

Hat man das Testdatenmanagement bereits in großem Stil umgestellt, wäre es doch reinste Verschwendung nicht darauf zu achten, dass die Daten auch in Zukunft immer noch verfügbar, und dass bereits lange zurückliegende Testergebnisse immer noch reproduzierbar sind.

Jeder Entwickler, jeder Projektleiter, jeder IT-Student und Hobbyprogrammierer verwendet irgendeine Art von Versionierungssoftware (Git, SVN, etc.). Das wirft für uns eine simple Frage auf:

Warum machen wir das nicht mit unseren Testdaten genauso?

 

Testdaten auf Abruf

Die Idee der Testdatenversionierung ist noch jung, im professionellen Testdatenmanagement jedoch entscheidend. Testergebnisse sollen reproduzierbar sein. Auch Tests von älteren Releases und Versionen sind davon betroffen. Wenn die Entwicklung den Workflow stellenweise auf ein früheres Release zurückwechseln muss, sind die aktuellen Testdaten plötzlich unbrauchbar geworden. In dem Fall wäre sogar eine Golden Copy unbrauchbar. Die Entwickler und Tester wollen und müssen aber auch morgen weiterarbeiten und weitertesten können. In einem solchen Fall ist man froh, wenn dem Testdatenmanagement in der Planung und Entwicklung die gebührende Aufmerksamkeit geschenkt wurde.

Selbst schon bei simpleren Alltagssituationen eines Entwicklerlebens kann eine ordentliche Versionierung der Testdaten sinnvoll sein. Wirft beispielsweise ein Test mit zwei vermeintlich gleichwertigen Datensets einmal einen Bug wirft und einmal nicht, kann die Versionierung von großem Wert sein. Wie wir bereits weiter oben gelesen haben, bestehen Datensets oftmals aus verborgenen, komplexen Verstrickungen in der Datenbank. Im Debugging kann es von unschätzbarem Wert sein, wenn man auf alte Daten zurückgreifen kann, um auf nicht-offensichtliche Probleme im Code zu stoßen.

 

Testdaten auf Knopfdruck

Testdaten sind in der Regel komplexer als unser obiges – zugegebenermaßen sehr konstruiertes – Beispiel mit dem Geburtsdatum. In einer größeren Testumgebung mit dahinterliegender umfangreicher Datenbank ist es wahrscheinlich, dass wir für jeden Testfall spezifische Daten benötigen. Sehr häufig benötigt man für die Generierung der Testdaten verschiedener Testfälle jeweils mehrere Schritte. Es bedarf Vorbedingungen die hergestellt werden müssen, Verknüpfungen mehrerer Tabellen mit einer Mischung aus vorhandenen und synthetischen (oder zu synthetisierenden) Daten, bevor die eigentlich benötigten Testdaten zur Verfügung stehen.

Selbst wenn wir uns um die Datengenerierung nicht mehr kümmern brauchen, sind die Daten an dieser Stelle im TDM Prozess immer noch manuell zu extrahieren oder es müssen zuvor manuell Transaktionen zum Herstellen der Vorbedingung durchgeführt werden.

Wir wollen daher für jeden Testfall ein Modell erstellen, das beschreibt, welche Schritte nötig sind, um Testdaten für den jeweiligen Testfall zu erhalten. Tools unterstützen uns dabei, diese Modelle einfacher zu definieren, indem möglichst simple Regeln auf die Testdaten angewandt werden. So kann man – ähnlich einer Äquivalenzklassenanalyse – Regeln für die Parameter der benötigten Daten erstellen, durch die am Ende auf Knopfdruck ein valides Datenset entsteht.

Somit ist der Schritt zur Testdaten-Automatisierung vollzogen. Wo vor kurzem noch jeder Entwickler und jeder Tester mehrere zeitaufwändige Schritte in der Datenbank manuell durchführen musste, können wir jetzt in Sekundenschnelle eine fast beliebige Anzahl an gültigen Daten generieren.

Allerdings sind die Daten, die wir erhalten immer noch Klarnamen, reale Anschriften, echte Sozialversicherungsnummer, wahre Kontostände und andere zu schützende Daten. Wer schafft hier Abhilfe? Und warum eigentlich? Mehr dazu in meinem nächsten Artikel, wo ich die EU-Datenschutzrichtlinie ins Visier nehmen werde und wo wir uns die Fringe Benefits von professionellem Testdatenmanagement noch genau ansehen werden.

 

Passende Artikel

Kommentare gesperrt.