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 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:

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 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