Testdaten
Inhaltsverzeichnis
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 Systeme 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 Verkaufs-Prozess 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 beispielweise 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 des 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 es eine Kombination aus 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:
- Die Lösung entkoppelt den Testfall von anderen Aktivitäten und kann flexibel jederzeit sofort ausgeführt werden.
- 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:
- 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).
- 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.
- 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
Testdaten auf Bestellung
Einige Projekten 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 Testaten 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:
- 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.
- 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.
- 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?
Leider ist das Testen mit personenbezogenen Daten 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: Leider ist das Testen mit personenbezogenen Daten 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 HowTo oder als Rechtberatung. 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. Im Bezug auf ihre datenschutzrechtlichen Bedenken werden die jeweiligen Compliance-Abteilungen jedoch regelmäßig damit "abgespeist", dass für diese Gelder eine echte Entfernung der personenbezogenen Daten nicht mal ansatzweise möglich wäre.
Neben den datenschutzrechtlichen Bedenken, die bei der Verwendung von Produktionsabzügen als Testdatenbestand ganz klar im Vordergrund stehen, gibt es noch ein
Testdaten aus einem Testdatengenerator
Die Bandbreite an Testdatengeneratoren
