Testdaten

Was sind Testdaten

Wenn man es mal ganz oberflächlich durch die Brille des operativ arbeitenden Testers betrachtet, dann sind Testdaten die Daten, die er im System benötigt um seinen Test durchzuführen. Wenn das System Under Test (SUT) ein Taschenrechner ist, dann benötigt der Tester keine Testdaten um beispielsweise alle zugesicherten Eigenschaften zur Addition zu überprüfen. Wenn die zu testende zugesicherte Eigenschaft aber die Memory-Funktion des Taschenrechners betrifft, dann müssen im Memory ggf. Daten enthalten sein um den Test durchzuführen. Vermutlich würde der Tester in diesem Falle einfach das Einbuchen der erforderlichen Daten in das Memory des Taschenrechners als ersten Prozessschritt zum Bestandteil des Testfalles machen. Werden die Systeme größer und komplizierter steigt in der Regel der Bedarf an Testdaten und auch der Aufwand um diese zu erzeugen.

Stellen Sie sich ein System mit Kontakt- und Adressdaten einer fiktiven Firma vor. Das System unterscheidet zwischen Interessenten (Kontakte, die noch nichts bei der Firma gekauft haben) und Kunden (Kontakte, die mindestens einen Kauf erfolgreich getätigt haben). Wenn es sich bei dem System um ein ordentliches ERP handelt, dann wird es nicht einfach ein Schalter am Kontakt geben, wo der Tester bei der Erstellung seiner Testdaten zwischen Interessent und Kunde umschalten kann. In der Regel wird es viel mehr so sein, dass der Verkaufsprozess mit einer Bestellung, einem Rechnungsausgang und einer Eingangszahlung durchlaufen werden muss, damit der Kontakt vom System als "Kunde" ausgewiesen wird.

Merke: Oft sind Daten im System das Ergebnis eines Prozesses, nicht einer direkten Erfassung. Benötigt der Tester bestimmte Datenkonstellationen für seinen Test, muss er ggf. einen umfangreichen Prozess durchlaufen.

Oft sind Prozesse abhängig von einem Zeitlauf. Wenn die fiktive Firma beispielsweise zugesicherte Eigenschaften des automatischen Mahnlaufes testen möchte, dann gibt es da sicher auch Testfälle, die überprüfen, ob offene Posten nach 30 Tagen automatisch angemahnt werden. Offensichtlich braucht man für einen solchen Test Kunden mit offenen Posten, die vor 30 Tagen gebucht wurden. Würde der Tester diese Testdaten selbst anlegen müssen, würde der Prozess also - neben dem tatsächlichen Aufwand - auch noch 30 Tage Laufzeit in Anspruch nehmen.

Merke: Es gibt eine Vielzahl von Einflussgrößen, die bestimmen ob das Erstellen von Testdaten durch den Tester im Verlauf der Testdurchführung überhaupt möglich ist. Zu diesen Einflussgrößen gehört die kleinstmögliche Prozesslaufzeit, Zugriffsbarrieren, Oberflächenrestriktionen, etc.

Woher kommen Testdaten

In der Regel finden wir in Projekten nicht nur eine Antwort auf diese Frage. Meist kommt eine Kombination von Lösungen zum Einsatz. Dabei wäre hier besonders viel Potential für Einsparungen und vor allem für eine Lösung, die auch die volle Zustimmung der Compliance-Abteilung finden würde.

Testdatenerstellung als Teil der Testausführung

Im diesem Falle legt der Ausführende (Mensch = manuell, Maschine = automatisch), wie oben beschrieben, alle von ihm benötigten Daten selbst an. Diese Lösung hat zwei große Vorteile:

1. Die Lösung entkoppelt den Testfall von anderen Aktivitäten und kann flexibel jederzeit sofort ausgeführt werden.
2. Der Testfall ist jederzeit einfach wiederholbar.

Trotz dieser beiden großen Vorteile, kommt diese Lösung in der Praxis kaum zum Einsatz. Vor allem drei Faktoren verhindern den Einsatz:

1. Die Kosten (nur manuell). Testdatenerstellung als Teil der Testausführung erhöht den Durchführungsaufwand um ein Vielfaches und verhindert Preissenkungsmaßnahmen (Zukauf preiswerter Ressourcen, Outsourcen).
2. Oberflächenrestriktionen. An einem großen, komplexen System gibt es in der Regel viele Prozesse, die durch die Oberfläche nicht bedient werden können.
3. Robustheit gegen Veränderungen des SUT. Mit jedem Release verändert sich das SUT. Enthält ein Testfall viele Schritte (über das eigentliche Überprüfen der zugesicherten Eigenschaft hinaus), ist die Wahrscheinlichkeit um ein vielfaches größer, dass der Testfall schon durch kleine Veränderungen des SUT - selbst an Funktionen, die fachlich gar nichts mit dem Test zu tun haben - nicht mehr lauffähig ist. Dies trifft im höchsten Maße auf Testfälle zu, die sich der Applikationsoberfläche bedienen. Aus diesem Grunde versucht man häufig, die Testfälle zu kürzen und damit vermeidlich robuster gegen Änderungen des SUT zu machen, indem man die Erstellung benötigter Testdaten aus dem Testfallablauf heraus nimmt.

Testdaten auf Bestellung

Einige Projekte bieten ihren Testern die Bereitstellung von Testdaten auf Bestellung an. In der Regel stellt dabei ein speziell ausgebildetes und mit Werkzeugen ausgestattetes Team, das Bestellungen (z. B. per Mail) entgegen nimmt, möglichst zügig die geforderten Testdaten bereit. Die dabei verwendeten Tools haben die Aufgabe, auch solche Daten ad hoc bereit zu stellen, die sonst nur durch einen aufwendigen Prozess entstehen würden. Diese Lösung hat vor Allem den Vorteil, dass komplexe Testdaten schneller und preiswerter zur Verfügung gestellt werden können. Die Nachteile dieser Lösung sind vor Allem:

1. Der hohe Initialaufwand. Ein solches Team mit der Ausrüstung und den Bestellprozessen zu implementieren, liegt nur für größere Projekte im Bereich des Machbaren.
2. Nicht unerheblicher Reibungsverlust. Tester und Techniker sprechen oft nicht die gleiche Sprache. Die Erfahrung zeigt, dass besonders das Formulieren von Testdaten-Anforderungen oft zu Missverständnissen führt.
3. Reaktionszeiten. Wenn die Bereitstellung der bestellten Testdaten nicht sofort erfolgt, muss der Tester warten. Erfahrungsgemäß kann dieses Problem durch "Vorab-Bestellung" und "Lagerhaltung" von Testdaten nur unzureichend adressiert werden.

Testdaten aus der Produktion

Die tatsächlich meist gesehene Lösung für die Herausforderung der Testdatenbeschaffung, ist die Beladung eines Testsystems mit einem Datenabzug aus der Produktion. Diese Option steht natürlich nur in Umfeldern zur Verfügung, in denen es nicht um eine völlige Neuentwicklung geht, sondern z. B. um Änderungen / Erweiterungen eines bereits produktiv genutzten Systems.

In der Regel läuft dieses Szenario so ab, dass in regelmäßigen Abständen (vierteljährlich o. ä.) ein Abzug aus der Produktionsumgebung gemacht wird. Dieser wird dann in unterschiedlicher Art und Weise bearbeitet. Manchmal wird der Datenbestand reduziert, oft wird er verfremdet, gelegentlich wird er ganz so belassen, wie er extrahiert wurde. Im nächsten Schritt wird das Testsystem neu aufgebaut und mit den Daten des Abzuges beladen. Ist das Testsystem mit dem Datenbestand beladen, können sich die Tester die benötigten Datenkonstellationen aus dem System suchen und mit ihnen die Tests durchführen.

Ohne Veränderung

Die Daten aus dem Produktionssystem 1 zu 1 in das Testsystem zu laden ist sicherlich am schnellsten und am preiswertesten zu realisieren. Solange keine personenbezogenen Daten im Spiel sind, ist die Verwendung der Produktionsdaten ohne Verfremdung sicher kein Problem. Aber welche Systeme enthalten keine personenbezogenen Daten? Fakt ist: Das Testen mit personenbezogenen Daten ist schlicht verboten!. Nun werden gerade Berater, die die Projektrealität kennen, sagen: "Das ist doch aber Alltag und wird nahezu überall gemacht." Auch nach reichlicher Überlegung ist den Autoren dieses Wikis keine Antwort auf diesen Einwand eingefallen, die hierher passen würde. Es bleibt nur zu wiederholen: Das Testen mit personenbezogenen Daten ist schlicht verboten! Daraus ergibt sich eine klare Folge: Datenabzüge, die personenbezogenen Daten enthalten, sind keine Testdaten.

Mit Entfernung aller personenbezogenen Daten

"Pseudonymisieren", "Anonymisieren", "Verfremden": All diese Begriffe werden gern verwendet, um zu beschreiben wie Datenabzüge so verändert werden, dass sie keine personenbezogenen Daten mehr enthalten. In der Praxis ist das vollständige Entfernen aller personenbezogenen Daten leider nicht so einfach, wie man erstmal annehmen könnte. Dieses Wiki versteht sich nicht als "HowTo" oder als Rechtsberatung. Die Erfahrung hat aber gezeigt, dass diverse europäische Konzerne jährlich hohe sechs-stellige Beträge für das Bereitstellen von Testdatenbeständen aus Produktionsumgebungen ausgeben. In Bezug auf ihre datenschutzrechtlichen Bedenken werden die jeweiligen Compliance-Abteilungen jedoch regelmäßig damit "abgespeist", dass für vertretbare Budgets eine echte Entfernung der personenbezogenen Daten nicht mal ansatzweise möglich wäre. Es wäre zu viel des Guten hier ins Detail zu gehen: Aber das Ersetzen der Namen und Adressen mit Phantasie-Werten ist aus Sicht des Datenschutzes nicht ausreichend und technisch bereits oft viel aufwendiger als es den Anschein hat.

Neben den datenschutzrechtlichen Bedenken, die bei der Verwendung von Produktionsabzügen als Testdatenbestand ganz klar im Vordergrund stehen, gibt es noch eine Vielzahl anderer Herausforderungen im Umgang mit Echtdaten. So ist die Reduzierung des Datenbestandes auf eine nutzbringende Größe oft schwierig. Das Auffinden von Datenkonstellationen, die für bestimmte Testfälle benötigt werden, erzeugt weiteren Aufwand und führt oft nicht zum gewünschten Ergebnis. "Nebenwirkungen" durch den Testfall nicht betreffende Veränderungen an den Daten bereiten Testern Kopfzerbrechen.

Testdaten aus einem Testdatengenerator

Oft sind Testdatengeneratoren eine stark unterschätzte Option bei der Bereitstellung von Testdaten. Allerdings ist auch die Bandbreite der angebotenen Leistungen unerwartet groß. Einige Testdatengeneratoren verstehen sich lediglich auf die Ermittlung von Datenkonstellationen, die dem Tester dann beispielsweise in einem Excel oder einem anderen Datenformat zur Verfügung gestellt werden. Es ist dann die Aufgabe des Testers, dieses Excel in seine Applikation zu laden. Anscheinend geht manch ein Hersteller von Testdatengeneratoren davon aus, dass jede Anwendung einem Tester eine einfache Excel-Ladefunktion zur Verfügung stellt. Aus Erfahrung lässt sich aber sagen: Dem ist sicher nicht so. Außerdem steht immer noch die Tatsache im Raum, dass Daten häufig das Ergebnis eines Prozesses sind. D. h. der Testdatengenerator muss in der Lage sein, die Prozessschritte im Testsystem anzustoßen, deren Ergebnis die Datenkonstellation ist, anstatt die Testdatenkonstellation direkt auszugeben.