Ist man als Berater im Umfeld von Microsoft ALM im Bereich Testmanagement unterwegs, so kommt des Öfteren die Fragestellung auf, wie mit Abhängigkeiten von Test Cases im TFS umgegangen werden kann. Die kurze Antwort darauf lautet: “Es kommt darauf an.”
Um die Frage also wirklich beantworten zu können, muss man zunächst die Art der bestehenden Abhängigkeit zwischen den Test Cases bestimmen. Dabei gibt es grundsätzlich zwei Stufen: In der einfachen Form besteht die Abhängigkeit erst einmal nur darin, dass die Test Cases in einer bestimmten Reihenfolge ausgeführt werden müssen. D.h. es existiert eine Vorgänger-Nachfolger-Beziehung zwischen Test Cases, wobei ein Test Case erst dann ausgeführt werden kann, wenn alle seine Vorgänger Test Cases erfolgreich durchgeführt wurden. In der erweiterten Form der Abhängigkeit spielt nicht nur die Reihenfolge der Ausführung der Test Cases eine Rolle. Vielmehr bilden Daten, welche innerhalb der Ausführung eines Test Cases generiert werden den Input für weitere Test Cases (vgl. Abb. 1).
Abb. 1: Beispiel einfache vs. erweiterte Abhängigkeit von Test Cases
In der Theorie sollten keine der beiden Abhängigkeitsformen im Test Design eine Rolle spielen sondern durch geeignetes Schneiden der Test Cases oder aber entsprechendes Testdatenmanagement vermieden werden. In der Praxis gibt es jedoch immer wieder Fälle, in denen dies insbesondere in den höheren Testarten, wie z.B. Integrations- oder User Acceptance Tests, und aus verschiedensten Gründen, wie z.B. hoher Komplexität sowie damit verbundenen hohen Kosten zur Erzeugung von adäquaten Testdaten, nicht umgesetzt werden kann.
In diesen Fällen ist es also wichtig die bestehenden Abhängigkeiten im TFS abzubilden, um eine reibungslose Testausführung zu ermöglichen. Out-of-the-Box sind die Möglichkeiten, die der TFS bzw. der Microsoft Test Manager (MTM) hierfür bietet jedoch sehr begrenzt. Daher haben wir in unseren verschiedenen Projekten Ansätze gesammelt, wie damit umgegangen werden kann, welche wir Ihnen im Folgenden vorstellen möchten:
Einfache Abhängigkeit von Test Cases
Im Falle der einfachen Abhängigkeit gibt es out-of-the-Box im MTM die Möglichkeit Test Cases in einer statischen Test Suite in eine Reihenfolge zu bringen. Dazu wird die Order-Funktion verwendet. Diese erlaubt es die einzelnen Test Cases händisch zu nummerieren (vgl. Abb. 2) . Die Test Cases werden dann in der dadurch definierte Reihenfolge ausgeführt. Wichtig hierbei ist es zu wissen, dass diese Funktion nicht im TFS Web Access zur Verfügung steht und auch die im MTM definierte Reihenfolge nicht in den TFS Web Access synchronisiert wird und somit auch nicht im TFS Web Test Runner zur Verfügung steht. Nutzt man also diese Art zum Festlegen der Ausführungsreihenfolge von Testfällen, ist man bei der manuellen Testausführung auf den MTM angewiesen und kann nicht den leichtgewichtigeren Web Test Runner verwenden.
Des weiteren ist diese im MTM implementierte Sortierfunktion nicht per Drag & Drop bedienbar sondern kann nur durch die Angabe von Nummern definiert werden. Aufgrund dessen ist diese Funktion für eine große Anzahl an Test Cases innerhalb einer statischen Suite kaum mehr praktikabel. Umfasst eine statische Suite jedoch nur eine geringe Anzahl an Test Cases und sind die notwendigen Lizenzen vorhanden um den MTM nutzen zu können, ist dies wohl die einfachste Möglichkeit eine Reihenfolge für die Ausführung von Test Cases zu definieren.
Abb. 2: Order-Funktion für statische Test Suites im MTM
Ein zweiter Ansatz eine Reihenfolge für Test Cases zu definieren, welche nicht ausschließlich an den MTM gebunden ist, ist es ein benutzerdefiniertes Feld zum Work Item Typen Test Case hinzuzufügen. In diesem kann analog zur Order-Funktion im MTM die jeweilige Nummer eines Test Cases in der Ausführungsreihenfolge definiert werden. Das Feld kann dann als Spalte angezeigt werden, nach welcher sortiert werden kann. Da sowohl im MTM als auch im TFS Web Access beim Ausführen aller Test Cases innerhalb einer Test Suite die Anzeigereihenfolge als Ausführungsreihenfolge verwendet wird, hat man so ebenfalls eine relativ einfache Möglichkeit gefunden mit Abhängigkeiten umzugehen.
Ein erheblicher Nachteil bei diesem Ansatz besteht darin, dass er nur zuverlässig anwendbar ist wenn sich die jeweiligen Test Cases nur in einer einzigen Test Suite befinden, da ansonsten die über das benutzerdefinierte Feld definierte Nummer nicht eindeutig ist. D.h. befindet sich ein und derselbe Test Case in mehreren Test Suiten, ist nicht klar auf welche Test Suite sich die Nummerierung in dem Feld bezieht. Mittels vordefinierter Nummernkreise lässt dieses Symptom zwar lindern, aber es bleibt ein Workaround, welcher auf bestimmte Szenarien begrenzt ist.
Ein letzter Ansatz um einfache Abhängigkeiten von Test Cases zu definieren ist es in der jeweils übergeordneten Test Suite die Reihenfolge der Test Cases festzuhalten. Hierfür kann wiederum ein benutzerdefiniertes Feld oder ein bereits bestehendes verwendet werden. Bei der Test Ausführung muss der Tester dann die Test Suite parallel geöffnet haben und ist selbst dafür verantwortlich die Test Cases in der gegebenen Reihenfolge ausführen.
Dieses Vorgehen birgt auf der einen Seite eine sehr hohe Fehleranfälligkeit, da die Reihenfolge nicht auf den ersten Blick ersichtlich ist und nicht bei der Ausführung automatisch übernommen wird. Auf der anderen Seite jedoch kann es auch verwendet werden, wenn sich Test Cases in verschiedenen Test Suiten befinden. Außerdem kann man dem Tester weitere ggf. notwendige Hinweise für die Testausführung geben.
Erweiterte Abhängigkeit von Test Cases
Für den Fall einer erweiterten Abhängigkeit (Output-Input-Datenabhängigkeit) zwischen Test Cases bietet der TFS weder im TFS Web Access noch im MTM eine dafür dedizierte Möglichkeit zur Umsetzung. In vielen Fällen ist es ausreichend in der Beschreibung der Test Steps Bezug zu nehmen, z.B. “Öffnen des vorher generierten Datensatzes”. Dies setzt jedoch voraus, dass der gleiche Tester beide Stellen testet. Insbesondere im Bereich der User Acceptance Tests können beispielsweise Key User aus den verschiedenen Organisationseinheiten zum Einsatz kommen, die das System später auch verwenden. Wenn man nun beispielsweise einen Bestellprozess in einer ERP-Anwendung unter realen Bedingungen testen möchte, so sind daran verschiedene Tester beteiligt. In solchen Szenarien braucht man andere Ansätze, um die Datenabhängigkeit abzubilden.
Eine Möglichkeit dafür besteht darin, den zuletzt vorgestellten Ansatz zur Definition einer Ausführungsreihenfolge zu erweitern. D.h. in der jeweils übergeordneten Test Suite werden die bestehenden Datenabhängigkeiten zum einen vorab definiert und zum anderen während der Testausführung die konkreten Daten dokumentiert (z.B. in Form einer Tabelle; siehe Abb. 3). Die generierten und so dokumentierten Daten können dann in darauf aufbauenden Test Cases weiterverwendet werden.
Dieser Ansatz kann mit den vorgestellten Möglichkeiten zur Definition einer Ausführungsreihenfolge kombiniert werden, wobei die bereits vorgestellten Vor- und Nachteile zu beachten sind.
Abb. 3: Beispiel für Definition von Input-Output-Abhängigkeiten innerhalb einer Test Suite
Dies funktioniert auch bei der Wiederverwendung von Test Cases, da diese typischerweise in unterschiedlichen Test Suiten, ggf. in verschiedenen Testplänen referenziert werden. Die Test Suite bleibt dabei jedoch eindeutig und demnach sind die entstandenen Daten auch spezifisch für eine Test Suite gespeichert.
Weitere Überlegungen
Bei den vorgestellten Formen der Abhängigkeit zwischen Test Cases kann es wie vorher beschrieben vorkommen, dass die voneinander abhängigen Test Cases von unterschiedlichen Testern, z.B. aus unterschiedlichen Fachbereichen oder Abteilungen, durchgeführt werden müssen.
In diesem Fall muss signalisiert werden, wann ein Test Case zur Ausführung bereit ist. Hierfür kann man zunächst alle Test Cases bis auf den als erstes auszuführenden als Blocked markieren. Nach der erfolgreichen Ausführung eines Test Cases werden dann alle darauf aufbauenden Test Cases zurück auf Active gesetzt. Damit wird dem jeweils zuständigen Tester signalisiert, dass der Test Case bereit zur Ausführung ist. Dieses Vorgehen wird für alle Test Cases fortgeführt (vgl. Abb. 4).
Abb. 4: Test Cases als Blocked / Active markieren
Fazit
Out-of-the-Box bietet der TFS keine Möglichkeit an Abhängigkeiten von Test Cases abzubilden und bei der Testausführung zu berücksichtigen, welche durchgängig sowohl im TFS Web Access als auch im MTM nutzbar ist.
Die vorgestellten Ansätze um sowohl Abhängigkeiten in Form von Ausführungsreihenfolge als auch Output-Input-Abhängigkeiten abzubilden sind in diversen Projekten entstanden und basieren darauf, innerhalb der TFS Testtoolkette zu bleiben, d.h. kein separates Tool zu verwenden. Sie sind keine Pauschallösungen, welche alle Szenarien abdecken, sollen aber Denkanstoß sein, wie man mit diesen Themen umgehen kann.
Haben Sie bereits selbst Erfahrungen mit einer der vorgestellten Ansätze gesammelt oder haben Sie selbst weitere Ansätze zum Umgang mit Abhängigkeiten von Test Cases im TFS entwickelt? Gerne senden Sie uns ihr Feedback zu diesem Thema.