Struktur ist alles

Die Vorteile einer effektiven Struktur für die Testautomatisierung

Günther Matthias Bär

Sowohl bei der Entwicklung von Software als auch in der Testautomatisierung ist es unerlässlich, eine logische Struktur aufzubauen. Das Ziel dabei ist es, zu jedem Zeitpunkt den Überblick zu behalten, die Arbeit im Team zu erleichtern und unabhängig von der Größe des Projekts wartungsfreundlich zu bleiben. Die Strukturierung von Programmen ist ein Verfahren, dass sich zum größten Teil in der Entwicklung von Software bereits etabliert hat. Die Erfahrungen haben gezeigt, dass dies in der Gänze aber noch nicht in die Testautomatisierung durchgedrungen ist. Dabei sollten hier die gleichen Anforderungen wie in der Entwicklung gestellt werden, denn oft kann die Testautomatisierung die gleiche Komplexität erlangen wie die zu testende Software. Es gibt bereits ausreichend Beispiele, die zeigen, wie eine logische Struktur aufgebaut werden kann.

ÄNDERUNGEN UND ANPASSUNGEN

Anwendungssoftware unterliegt in der Entwicklung einem ständigem Änderungsprozess. Mit jedem Release müssen neue Funktionalitäten überprüft werden. Dies zum Teil in unterschiedlichen Konfigurationen und/oder mit geänderten Randbedingungen (anderes Betriebssystem, unterschiedliche Browser, etc.). Eine Testautomatisierung muss deshalb so aufgebaut sein, dass zeitnah auf jede Änderung im System Under Test (SUT) reagiert werden kann. D.h. Änderungen am Testautomatisierungs-Framework dürfen nicht mehr Aufwand bedeuten als die durchgeführten Anpassungen im SUT. Anforderungen hinsichtlich kürzerer Releasezyklen (Time to Market) sowie einer deutlichen Verbesserung gegenüber der manuellen Testdurchführung, wie z.B. Reduktion der Kosten, Erhöhung der Testintensität/Komplexität, kürzerer Laufzeiten und einer geringeren Fehleranfälligkeit, machen es zudem erforderlich, dass die Gesamtheit aller Testfälle in einem definiertem Zeitrahmen ablaufen müssen. Eine gut strukturierte Architektur der Testautomatisierung ermöglicht z.B. eine effektivere Lastverteilung der durchzuführenden Testfälle und kann somit den Anforderungen besser gerecht werden. Ein weiterer wichtiger Aspekt ist die
Wartbarkeit einer Testautomatisierung. Eine zentrale Verwaltung von Variablen bzw. Testdaten minimiert den zu erbringenden Änderungsaufwand. Eine vernünftige Aufteilung von themenspezifischen Funktionalitäten in eine modulare Struktur erhöht die Übersicht und erleichtert das Arbeiten im Team. Des Weiteren ist auf eine Synchronität zwischen der zu testenden Software und der Testautomatisierung zu achten, d.h. jede durchgeführte Änderung im SUT sollte einer Änderung in der Testautomatisierung einfach zuzuordnen sein. Eine Testautomatisierungsstruktur muss es ermöglichen, dass unabhängig von der Testtiefe die Testfälle zu jedem Zeitpunkt wiederholt werden können. Dies wiederum setzt voraus, dass vor bzw. nach jedem Testlauf (Setup bzw. Teardown) die zu testende Applikation auf den Urzustand zurückgesetzt werden kann. Dies bedeutet, dass das Testdatenmanagement eigenständig behandelt und aus jeder Phase des Testlaufs ansprechbar sein muss. Da so gut wie jedes Testframework über Monitoring- bzw. Log- und Reporting-Mechanismen verfügt, wird durch den Aufbau einer effektiven Struktur das Auffinden und Beheben von Fehlern erleichtert. Bevor der erste Testfall erstellt werden kann, sollte man sich also zunächst über den Aufbau der Architektur der Testautomatisierung Gedanken machen. Dies mag vordergründig mehr Aufwand bedeuten, aber dieser Mehraufwand zahlt sich bezogen auf das Gesamtprojekt aus.

EIN GLEICHNIS AUS DEM LEBEN

Stellen Sie sich vor, Sie sollen mit einer Gruppe von Leuten aus Legosteinen ein bestimmtes Modell (Haus, Flugzeug, Schiff, etc.) in einem bestimmten Zeitrahmen erstellen. Ihnen steht hierzu eine riesige Kiste aus unterschiedlichen unsortierten Steinen zur Verfügung. Sie wären also gezwungen, jedes einzelne benötigte Teil in der Kiste zu suchen (einhergehend mit Kopfschmerzen, da sie permanent mit den Köpfen der Kollegen zusammenstoßen). Sie wüssten auch nicht, ob ein bestimmtes Teil überhaupt vorhanden bzw. verwendbar ist (da gebrochen oder ähnliches). Sie müssten also entscheiden, ob es Sinn macht weiter zu suchen oder das Teil neu zu besorgen, um im zeitlichen Rahmen zu bleiben. Sie sehen, es können vielfältige technische, administrative und logistische Probleme auftreten. Wäre es da nicht sinnvoller, im Vorfeld etwas Mühe hineinzustecken und die einzelnen Steine zu sortieren und auf kleinere Behälter zu verteilen? Die Zeit für die Suche im Team verkürzt sich immens. Wenn ein bestimmtes Teil benötigt wird, muss nur auf das entsprechende Behältnis zugegriffen werden und man kommt sich nicht mehr zwangsläufig gegenseitig in die Quere. Fehlerhafte Teile werden zudem schneller entdeckt. Fehlende Teile können zeitnah besorgt werden.

PROGRAMMIERUNG ERLEBEN

Ähnlich verhält es sich auch in der Software-Entwicklung. Auf Grund eines vermeintlich höheren Aufwands scheuen viele Entwickler davor zurück, sich darüber Gedanken zu machen, wie sich bestimmte Teile einer Funktionalität thematisch, funktional und logisch in einzelne Module bzw. Untermodule aufteilen lassen. Das Ergebnis sind dann meist monolithische Softwarekonstrukte (also „Kruschkisten“), die oft nur noch schwer zu verwalten sind. Müssen in einem solchen Konstrukt nun entsprechende Änderungen vorgenommen werden, ist zu gewährleisten, dass nur eine Person diese Datei ändert, um zwangsläufig auftretende Probleme (wie z.B. gegenseitiges Überschreiben von Änderungen) zu vermeiden. Wird diese Software in einem zentralen Versionierungstool verwaltet, ist die entsprechende Datei für eine weitere Bearbeitung sowieso gesperrt, d.h. es leidet unter anderem die Wartbarkeit der Software darunter. Allein durch den Aufbau einer logischen Verzeichnisstruktur, die die Struktur der zu testenden Software widerspiegelt und einer sinnvollen Vergabe von Dateinamen der einzelnen Module wird sozusagen eine Verbindung zum zu testenden System hergestellt und es lassen sich zu bearbeitende Dateien leichter auffinden. Dies erspart unnötige Sucharbeit. Durch die Verwendung kleinteiliger Module werden bei einem Testlauf auch nur noch die Teile geladen, die auch wirklich benötigt werden.

WIE KANN NUN SO EINE STRUKTUR IN DER PRAXIS AUSSEHEN?

Als Beispiel wollen wir hier ein End-to-End-Testszenario einer Web-GUI heranziehen, das mittels einer schlüsselwortgetriebenen Testware realisiert wird. Zunächst wollen wir die Struktur einer Web-Applikation näher betrachten: Grob gesagt besteht eine Web-Applikation aus einer Hauptseite und den entsprechenden Menü-Elementen, um auf die jeweiligen Unterseiten zu gelangen. Jede Seite enthält unterschiedliche Elemente (Lokatoren) und Funktionalitäten, die über die Testautomatisierung angesprochen werden
müssen. Aus diesem Grund macht es also Sinn, die Funktionalität einer jeden aufgerufenen Seite in einem Pendant auf Seiten der Testautomatisierung abzulegen. Dadurch begrenzt
sich der Umfang der Datei auf das Wesentliche, da nur die Eigenschaften der jeweiligen Seite angesprochen werden. Die Übersichtlichkeit wird erhöht und die Fehlersuche erleichtert. Ein sehr gutes Verfahren, das hier zur Anwendung kommen kann, ist das sog. Page/Page Objekt-Verfahren. Dabei wird die Testautomatisierung in drei primäre Teilbereiche unterteilt, die wie folgt beschrieben werden können:

• Testfallbeschreibung: Je nach zu testendem Abschnitt der Applikation werden parametrisierbare Testfälle in eigenständigen Testbeschreibungsdateien
  definiert.
• Abschnittsbeschreibung: In so genannten Page Files werden die entsprechenden Workflows der Abschnitte abgebildet.
• Zustandsbeschreibung: Über so genannte Page Object Files wird die Funktionalität der jeweiligen Seite abgebildet und die anzusprechenden Lokatoren hinterlegt.

Ein Vorteil dieser Strukturierung besteht unter anderem darin, dass für
jede Funktionalität nur die wirklich erforderlichen Zusatzmodule integriert
werden und somit ein Overhead vermieden werden kann.

TESTBESCHREIBUNGSDATEIEN

Jeder Menüpunkt einer Webapplikation stellt einen eigenständig zu behandelnden Abschnitt dar. In den einzelnen Schritten eines jeden Testfalls wird der vollständige Prozess bis hin zu dem jeweiligen Abschnitt durchlaufen, dessen Funktionalität überprüft und der Prozess wieder abgeschlossen. Ziel der Übung ist es nun, zu entscheiden wie die Testbeschreibungsdateien so aufgeteilt werden können, dass immer nur ein Abschnitt bzw.
Teilabschnitt behandelt wird. Dabei soll einerseits die Modularität und somit die Wartbarkeit erhöht, der Inhalt begrenzt und andererseits die Anzahl der zu verwendenden Dateien nicht
unnötig in die Höhe getrieben werden. Vor der Erstellung von automatisierten Testfällen in Testbeschreibungsdateien sollten also unter anderem folgende Fragen gestellt werden:

• Wie lassen sich die dokumentierten Testfälle sinnvoll unterteilen?
• Sollen gewisse Kategorien autark testbar sein?
• Ist ein bestimmter Workflow bei der Ausführung einzuhalten?
• Gibt es evtl. Überschneidungen mit anderen Testfällen?
• Wie soll der Zugriff auf entsprechende Testdaten erfolgen?
• Wie sollen testfallübergreifende Konfigurationen verwaltet werden?
• Wie sollen testfallspezifische Konfigurationen verwaltet werden?

PAGE FILES

Wie der Name schon vermuten lässt, bilden die Page Files die Funktionalität der einzelnen Abschnitte ab. Dies heißt nichts anderes, als dass die Menüführung der jeweiligen (Unter-)
Seiten abgebildet und zu eigenen Schlüsselwörtern zusammengeführt werden, um die Erstellung der Testfälle zu vereinheitlichen. Als einfaches Beispiel kann hier z.B. die Verwaltung von Personen einer fiktiven Web-Applikation genannt werden. Für das Anlegen, Bearbeiten oder Suchen von Personen sind eigenständige Seiten in der Web-Applikation vorgesehen. Jede dieser Seiten werden in der Testautomatisierung über eine eigene Datei abgebildet. Durch Aufruf von Schlüsselwörtern aus den Page Object Files können wiederum ganze Workflows zu einem Schlüsselwort in den Page Files zusammengefasst werden. Über die Möglichkeit unterschiedliche Testdaten über ein und dasselbe Schlüsselwort durchzureichen, können somit unterschiedliche Testszenarien abgebildet werden.

FAZIT

Etliche Testautomatisierungsprojekte leiden unter der Tatsache, dass nicht genügend Vorarbeit hinsichtlich der aufzubauenden Struktur geleistet wird. Damit einhergehende Probleme lassen sich aber vermeiden. Der vorgeschlagene Ansatz ist dabei nur einer von vielen Möglichkeiten wie man sich die Arbeit in der Testautomatisierung und insbesondere in einem Team erleichtern kann. Dabei verhält es sich wie beim Bau eines Hauses: Erst wird geplant und dann gebaut!