Testomaten auf Datensalat an Stressing
Eine besondere Herausforderung für jede manuelle Testdurchführung und ganz besonders für die Testautomatisierung sind die Testdaten. Bei den meisten manuellen Tests stehen in den Testfällen meist nur grobe Hinweise zu den zu verwendenden Testdaten. Das Vorgehen funktioniert in der Testautomatisierung nicht.
Im vorhergehenden Thema „Zutaten und Küchengeräte für Testomaten und wer ist der Koch“ habe ich darüber berichtet, welche Voraussetzungen für die Testautomatisierung gegeben sein müssen, um erfolgreich Automatisierung einzusetzen. Dabei habe ich bereits auf eine weitere Herausforderung hingewiesen: Die Testdaten. Dieses Thema möchte ich in diesem Blogeintrag nun etwas näher beleuchten.
Was passiert, wenn wir uns nicht um die Testdaten bei der Testautomatisierung kümmern und uns auf Testdaten stützen bei denen die Testautomatisierung nicht berücksichtigt wurde?
Testen kann man mit Kochen vergleichen. Das Rezept ist der Testfall und die Testdaten sind die Zutaten. Beim manuellen Testen folgen wir dem Rezept/Testfall und suchen die Zutaten/Testdaten nach Bedarf. Dies funktioniert beim automatisierten Testen nicht. Hier müssen die Testdaten bzw. die Zutaten exakt und vorportioniert vorliegen. Das heißt, es reicht nicht nur die Art und Form der Testdaten zu benennen, sondern es ist notwendig das genau die Instanz des Testdatums im Testskript benannt ist.
Zusätzlich werden beim Testen die Testdaten verbraucht bzw. die Testdaten altern. Also wie im Restaurant, irgendwann sind die Tomaten alle oder der Blattsalat wird welk. Wie bekommen wir also unsere passenden Zutaten und dies auch in einer ausreichenden Menge.
Oft höre ich in Projekten: „Wir machen einfach einen, hoffentlich anonymisierten, Produktionsabzug“. Der liefert jedoch nur einen Teil der benötigten Daten für die Testautomatisierung. Das heißt, für unveränderliche Stammdaten ist so ein Abzug sehr wohl nützlich. Nun bekommt der Koch in der Küche nicht immer die gleiche Bestellung für seinen Salat. Mal möchte der Gast den Salat mit oder ohne Oliven, mal mit Joghurtdressing, mal mit Essig und Öl. In Abhängigkeit der Zutaten bzw. Änderungen an der Bestellung ändert sich dann auch noch der Preis. Das heißt wir benötigen für unsere Testdaten auch veränderliche Daten so genannte Bewegungsdaten, um die Geschäftsprozesse vollständig abzubilden. Um die benötigten veränderlichen Daten für die Testautomatisierung bereit zu stellen gibt es zwei Ansätze und beide haben ihre Vor- und Nachteile. Beim ersten Ansatz werden die benötigten Daten aus dem anonymisierten Produktionsabzug herausgesucht. Der Aufwand die entsprechenden Filterkriterien zu ermitteln und anschließend in einer Abfrage zu formulieren kann jedoch schnell sehr hoch ausfallen. Der Nachteil ist dabei, dass die herausgefilterten Daten nur in begrenzter Anzahl zur Verfügung stehen und werden bei der Testdurchführung ggf. verbraucht.
Beim zweiten Ansatz werden die benötigten Testdaten in der Datenbank neu erstellt, so dass der Testfall über alle notwendigen Testdaten verfügt. Diese Testdaten werden zwar auch verbraucht, können jedoch durch die automatisierten Skripte immer wieder neu angelegt werden. Auch das Anlegen der so genannten synthetischen Testdaten kann, z. B. bei vielen abhängigen Daten, sehr aufwendig sein. Daher ist immer individuell abzuwägen, welche der beiden Ansätze für welchen Testfall zum Einsatz kommt.
Bei der Testautomatisierung ist es auch oft notwendig die Testdaten zu dynamisieren. Was heißt das? Nehmen wir wieder ein Beispiel aus der Küche. Bekanntlich muss eine gute Pekingente 24h vor dem Verzehr bestellt werden. Da das Verzehrdatum ein veränderliches Datum ist kann hier eine Dynamisierung die Lösung für die Automatisierung bringen. Das Ergebnis sieht dann so aus: Verzehrdatum = Bestelldatum + 24h. Solche oder ähnliche dynamischen Testdaten kommen auch bei der Testautomatisierung zum Einsatz.
Fazit, in den meisten Fällen ist es wie bei einem guten Salat – die Mischung macht‘s. Also hier nochmal das Rezept zusammengefasst. Man nehme als erstes einen anonymisierten Produktionsabzug für die grundlegenden und unveränderlichen Stammdaten (diese können auch bei kleineren Mengen selbst erstellt werden), dazu einige gut ausgewählte veränderliche Daten aus dem Produktionsabzug mittels Abfrage im Testfall. Nun noch eine gut ausgewählte Portion synthetische Testdaten. Das ganze gut abgestimmt mit dem Testfalltemplate. Zum Schluss noch ein Schuss dynamisierte Testdaten im Template oben drauf und fertig ist der perfekte Datensalat für unsere Testautomatisierung. Wichtig nach dem Anrichten der Testdaten in der Datenbank muss die Datenküche auch wieder gut aufgeräumt werden. Also alle statischen, synthetischen und dynamischen Testdaten in den Ausgangszustand bringen, falls sie durch den Testfall verändert wurden. Im Klartext bedeutet dies, dass jeder Testfall in der Nachbedingung ein Aufräumen der Testdaten beinhaltet, denn Sauberkeit ist in einer guten Datenküche oberstes Gebot.
Wie ja bekannt ist, kommen in der Küche auch verschiedene Geräte zur Automatisierung des Kochvorgangs zum Einsatz. Wie viele dieser Testautomaten für ein Projekt gut sind, behandeln wir in meinem nächsten Blogbeitrag aus der Reihe Kochrezepte für Testautomatisierung. Bis dahin happy Testing und immer eine gut aufgeräumte Datenküche.
Dieser Beitrag wurde verfasst von:
