Kolumne

Testdaten – Der unterschätzte Wert einer erfolgreichen Automatisierung

Thomas Garus

© Shutterstock / ByEmo

In dieser Folge der Kolumne „Test IT!“ geht Thomas Garus auf ein oft unterschätzes Thema ein: Wie sollte man Testdaten für eine stabile Testautomatisierung designen?

Der unterschätzte Wert einer erfolgreichen Automatisierung

Die letzten Jahre habe ich in den unterschiedlichsten Projekten für sowohl traditionelle Rich Clients als auch Webanwendungen gearbeitet. Dabei haben wir je nach Projektkonfiguration die Testautomatisierung mit verschiedenen Test Frameworks vorangetrieben. Bei jedem Projekt hat sich ab einem gewissen Punkt die Frage aufgetan, wie wir unsere Testdaten für eine stabile Testautomatisierung designen können.

Dabei geht die Frage nicht so sehr in die Richtung: „Welche Testdaten sind geeignet für unsere Automatisierung?“. Eher gehen wir der Frage nach: „Wie können wir in einem Projekt eine frische Datenbasis herstellen und exportierte Datendumps einspielen, damit wir die Testdaten nicht zur Testlaufzeit erzeugen müssen und unabhängige, einfach zu analysierende Testfälle bekommen?“

Wenn diese oder ähnliche Fragen in Ihrem Projekt auftauchen, haben Sie höchstwahrscheinlich bereits Anwendungsteile automatisiert getestet und Problemstellungen aufgedeckt. Wenn Sie gerade mit der Automatisierung im Projektkontext beginnen, sollten sie das Thema bald angehen, da sich sonst Problemen zeigen können.

Mögliche Probleme durch mangelhaftes Testdatenmanagement

  • Testfälle werden mit Abhängigkeiten zueinander spezifiziert, um eine aufeinanderfolgende Ausführung zu ermöglichen. Beispiele:
    • Zum Testen der Funktion „Kunde löschen“ muss zunächst der Test für „Kunde anlegen“ erfolgreich ausgeführt worden sein.
    • Zum Testen der Funktion „Produkt editieren“ muss zunächst der Test für „Produkt anlegen“ erfolgreich ausgeführt worden sein. Dies kann durch die Abhängigkeit zueinander für zusätzliche Fehler sorgen, die die Aussagekraft der Tests schmälern.
  • Es werden Testschritte geschrieben, die nur der Initialisierung von Testdaten für folgende Testfälle dienen
    • Bestenfalls verlängert sich dadurch nur die Testlaufzeit
    • Im schlimmsten Fall schlagen Testfälle oder gesamte Suites fehl – nicht etwa, weil der einzelne Testfall fehlerhaft war, sondern weil es Fehler während des Eintragens der benötigten Daten gab.
    • In beiden Fällen wird es schwerer, die Tests zu analysieren, da vorgelagerte Schritte ebenso umfangreich werden wie die eigentlichen Testfälle.
  • Der Testcode wird unübersichtlich und schwerer wartbar
  • Wahrscheinlich wird viel Zeit mit der Einführung von Workarounds verbracht, anstatt sich
    auf neue Testfälle zu konzentrieren.

Aus Erfahrung kann ich bestätigen, dass es durchaus kompliziert und langwierig sein kann, eine geeignete Testumgebung aufzubauen. In Hinblick auf zukunftsfähige, wartbare und ausführbare Tests sollte daher eine geeignete Testdatenstrategie verfolgt werden.

Testdaten-Strategien

Es existieren zahlreiche Strategien für die Arbeit mit Testdaten im Umfeld der Testautomatisierung. Nicht alle davon können und sollten in allen Phasen und Projektkonfigurationen eingesetzt werden. Lohnenswert ist es allemal sich einen Überblick zu verschaffen und bestehende Strategien auf die eigene Problemstellung zu erweitern. Für die folgenden Ansätze ist es ratsam, eine eigene, unabhängige Testdatenbank zu verwenden. Ansonsten kann es passieren, dass die Pläne im Bereich des Testdatenmanagements durchkreuzt werden, da ungewollte Datenänderungen in der gemeinsamen Datenbank durchgeführt werden.

Manuelle Testdatenerstellung inklusive Export und Import in die Testdatenbank

Bei fortgeschrittenen Projekten sind häufige Datenmodelländerungen weniger wahrscheinlich. Daher lassen sich in solchen Fällen umfangreichere automatisierbare Prozesse zum Export und Import von benötigten Testdaten realisieren. Um einen solchen klassischen Testdatenmanagement-Prozess aufzusetzen, müssen zunächst geeignete Testdaten für die gewünschten Testszenarien entworfen werden.

  1. Nachdem die benötigten Daten definiert sind, können diese manuell über die Benutzeroberfläche der Anwendung eingegeben werden. Über die bestehenden Mechanismen der Anwendung werden die Daten in der Datenbank gespeichert. Gleichzeitig ist dies ein guter erster Test, ob die Anwendung ordnungsgemäß funktioniert oder erste Fehlfunktionen kommuniziert werden müssen.
  2. Damit es nicht zu ungewollten Änderungen beim Eingeben neuer Daten kommt, sollte als Vorbereitung der aktuellste Datendump in die Datenbank eingespielt werden. Damit nur solche Daten hinzugefügt werden, die wirklich gebraucht werden, ist es sinnvoll für die Anwendung, Namespaces und Konventionen festzulegen. Dadurch lässt sich sicherstellen, dass alle Projektbeteiligten die Testdaten direkt den entsprechenden Testfällen zuordnen können.
  3. Sobald alle Daten über die GUI eingegeben wurden, kann die Datenbank in einem Format der Wahl (z.B. SQL-Dateien oder Dumpfiles) exportiert und gesichert werden (am besten versionsverwaltet, Stichwort „Konfigurationsmanagement“). Wenn die Datenbank für die Tests zurückgesetzt werden muss, müssen die Datenbanktabellen nur gelöscht und über die exportierten Skripte wieder eingespielt werden. Der komplette Prozess wird in Abbildung 1 dargestellt.
Abbildung 1: Workflow zur Erstellung von Testdaten

Abbildung 1: Workflow zur Erstellung von Testdaten

Testdatengenerierung durch Code

Sollte Ihre Anwendung im Entwicklungszyklus von häufigen Änderungen am Datenmodell betroffen sein, können Datenbankexporte oder SQL-Skripte nicht ausreichend sein. In solchen Fällen kann man eine „DataHelper“-Klasse definieren. Diese ruft direkt die Funktionen der Anwendung im Code auf und schreibt sie über geeignete Schnittstellen direkt in die Datenbank. Dies lässt sich z.B. über eine Java-Datenbankschnittstelle realisieren. Mit diesem Ansatz und geringem Programmieraufwand lassen sich definierte Mengen von Daten für die Testautomatisierung erzeugen. Der Nachteil ist die Skalierbarkeit: Bei großen Datenmengen kann die Durchlaufzeit schnell ansteigen.

Zurücksetzen der Testdatenbank

Nachdem darauf eingegangen wurde, welche Möglichkeiten der Testdatenerzeugung es gibt, muss betrachtet werden, wann die Testdaten in die Datenbank eingespielt werden. Es gibt mehrere Zeitpunkte während des Testprozesses, an dem die Testdaten im System zurückgesetzt und neu importiert werden können. Jeder Ansatz hat gerade in Hinblick auf die Ausführungsgeschwindigkeit seine spezifischen Vor- und Nachteile. Folgende zwei Ansätze sollten dabei in der engeren Auswahl stehen:

  • Testdaten werden nur zu Beginn der Testausführung zurückgesetzt. Dies ist der „normale“ Ansatz, um die Testumgebung für die Testausführung vorzubereiten.
  • Testdaten werden zu Beginn und zum Abschluss der Testausführung zurückgesetzt. Dieser Ansatz ist für Projekte interessant, in denen der Testdatenimport nicht allzu lange dauert. In einigen Projekten könnte dies als Failsafe angesehen werden, falls der erste Reset fehlschlägt. Hier gibt es allerdings einen entscheidenden Nachteil, der unbedingt beachtet werden sollte. In einigen Situationen kann es erwünscht sein, Daten zu haben, die durch einen Fehschlag der Tests erzeugt werden. Nur dadurch können einige Probleme in der Anwendung nachvollzogen werden. Durch den Datenbank-Reset nach der Testausführung würde diese Möglichkeit nicht bestehen.

Der geeignete Umgang mit Änderungen am Datenmodell

In den meisten Projekten werden die Testdaten über den Projektverlauf hinweg regelmäßig angepasst. Das Datenmodell der Anwendung wird sich vermutlich schon mal ändern, daher braucht man Ansätze, um auch zukünftig für diese Herausforderung gerüstet zu sein. Die Änderungen der Daten bzw. der Datenstruktur können entweder manuell über Änderungsskripte eingefügt werden, oder dieser Prozess wird automatisiert. Für einige Projekte kann es ausreichend sein, die Änderungen manuell einzufügen. Die meisten Projekte werden allerdings über kurz oder lang die Automatisierung vorziehen und entsprechende Schritte in ihren Buildprozess integrieren.

Dafür müssen Datenbankskripte vorhanden sein, welche die benötigten Änderungen in der Datenbank durchführen und diese dadurch aktualisieren. Der übliche Prozess zur Arbeit mit Testdaten und Datenmodelländerungen ist in Abbildung 2 dargestellt.

Abbildung 2: Testdatenerstellung mit Datenmodelländerungen

Setzen Sie sich für das Thema ein!

Die genannten Ansätze geben einen Einblick in ein ziemlich komplexes und kontextabhängiges Problemfeld. Nichtsdestotrotz bieten sie Diskussionspunkte für die geeignete projektspezifische Testdatenstrategie, die gemeinsam mit allen Teammitgliedern diskutiert werden sollte.

Unabhängig von der aktuellen Projektsituation ist es ratsam, sich für dieses Thema einzusetzen, damit schwerwiegende Probleme abgewendet werden können. Es steht außer Frage, dass dies einen zusätzlichen Aufwand für das Projekt bedeutet. Es wird jedoch Verbesserungsarbeit im Nachhinein ersparen, und das Testmanagement und die Testanalyse wird weniger komplex. Damit steigt der Nutzen der automatisierten Tests.

Das Thema ist interessant für alle Stakeholder des Projektes, und sie sollten zur Findung einer geeigneten Strategie eingebunden werden. Dadurch wird das Wissen im Team gestreut, und jeder kann sich an einer kontinuierlichen Verbesserung beteiligen. Am Ende ist es schließlich das Ziel, das gesamte Team von den aus den Tests gewonnenen Informationen profitieren zu lassen.

Genug der Vorrede: Jetzt sind Sie dran! Wie sind Ihre Erfahrungen im Bereich des Testdatenmanagements zur Testautomatisierung? Haben Sie Erfahrungen gemacht, von denen jeder mit einer ähnlichen Problemstellung profitieren sollte? Wenn ja, dann zögern Sie nicht, diese zu teilen und so die Diskussion anzuregen.

Mein besonderer Dank gilt Mario Kühne für seine Unterstützung während der Planungsphase dieses Artikels.

LESEN SIE AUCH:

Use-Case-Coverage durch Testautomatisierung

Verwandte Themen:

Geschrieben von
Thomas Garus
Thomas Garus
Thomas Garus ist Test Consultant bei der BREDEX GmbH in Braunschweig. Er hat in diversen traditionellen und agilen Projekten gearbeitet, in denen er für die Testkoordination, die Testautomatisierung für Desktop- / Webanwendungen und das Etablieren von Teststrategien zuständig ist. Darüber hinaus setzt er sich für einen einheitlichen Testgedanken und Prozessverbesserungen im Projektteam ein. Thomas ist zudem Mentor und Coach für neue Test Consultants in der Firma.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: