Testmanagement mit Jira - Ein (subjektiver) Vergleich

Der Ausgangspunkt

Die typische Herausforderung für Projektteams: Ein Zoo von Tools für die Verfolgung der Aufgabenerledigung, das Fehlermanagement, das Testmanagement, das Requirements Management, die Codeverwaltung usw.  Das Arbeiten mit vielen verschiedenen Systemen stellt einen ständigen Kontextwechsel dar, durch den wertvolle Arbeitszeit verloren geht, die besser in die Lösungserstellung investiert wäre. Jira ist insbesondere in agilen Umgebungen sehr verbreitet für die Aufgabenverfolgung und das Fehlermanagement. Daher bekommen wir in letzter Zeit immer häufiger Anfragen, ob und wie man Testmanagement mit Jira abdecken kann, um weniger Toolbrüche zu haben – und in einer Umgebung zu arbeiten.  Dahinter steckt das altbekannte Problem, welchen Trade-off zahle ich: das beste für die Aufgabe spezialisierte Tool oder möglichst viele Aufgaben mit einem Tool abdecken und dafür Kompromisse eingehen?

Genau solche Fragen habe ich in den letzten 2 Jahren immer wieder bearbeitet – nicht immer mit demselben Ergebnis. Es kommt wie immer auf die konkreten Bedürfnisse der Entwicklungsteams und -organisation an. Mit diesem Blog möchte ich drei häufig verwendete Apps skizzieren, die ich in verschiedenen Kundenumfelden betrachtet habe:

• Zephyr for Jira – Test Management von SmartBear
• Xray Test Management for Jira von Xpand IT
• TM4J – Test Management for Jira von Adaptavist

Zephyr for Jira für das Testmanagement mit Jira

Projektstruktur

Zephyr ist projektbasiert, d.h. das Testmanagement mit Jira ist hier jeweils nur innerhalb eines einzelnen Projektes gedacht. Daher funktioniert auch das Reporting nur innerhalb eines Projektes zuverlässig. Die App ermöglicht eine recht feingranulare Rechtevergabe an Gruppen oder User, was für weniger agile Umgebungen durchaus wichtig sein kann.

Zephyr ist für jedes Projekt der Jira Instanz aktiv, sofern es nicht über die Administration abgeschaltet wird. Bei den anderen getesteten Plug-Ins ist das umgekehrt: dort muss das Plug-In für ein Projekt aktiviert werden. D.h. nach Installation von Zephyr for Jira haben alle existierenden Projekte das Testmanagement freigeschaltet, bis der Administrator einzelne Projekte abschaltet. Je nach Anwendungsfall erweist dieses Verhalten für existierende Installationen als nachteilig, beispielsweise wenn das Testmanagement nur für einzelne Projekte benötigt wird oder wenn das Testmanagement pilotiert wird.

Testentitäten, Testplanung und Testausführung

Zephyr erweitert Jira um eigene Issue Types: Test und Test Cycle. In Zephyr gehören Testfälle immer zu einer festen Version bzw. bei Nichtzuordnung zur Version „unscheduled“. Das führt dazu, dass Testfälle kopiert oder geklont werden müssen, um sie mehrfach zu nutzen. Diese einfache und eher unhandliche Lösung sorgt für eine Inflation von Testfällen, alleine aufgrund der Versionen des zu testenden Systems. Ein Strukturieren der Testfälle wird in Zephyr über die Attribute Version, Komponente und Projekt eines Testfalls ermöglicht. Für größere Vorhaben ist das zu wenig, hier wird von den meisten meiner Kunden eine Ordnerstruktur bevorzugt, wie sie aus den spezialisierten Testmanagement-Tools bekannt ist.

Testzyklen können in Zephyr über Testpläne abgebildet werden. Diese werden grundsätzlich einem Testenvironment und einem Software-Build zugeordnet. Ein Testfall wird in einem Testzyklus genau einmal eingeplant, kann dann aber mehrfach ausgeführt werden.

Bei der Ausführung wird der Teststatus des Testfalls in Zephyr nicht aus den Status der einzelnen Testschritte ermittelt, sondern muss immer manuell gesetzt werden. Bei anderen Add-Ons kann der Teststatus des Testfalls meist wahlweise gesetzt werden oder er wird vom Add-On automatisch aus den Status der Testschritte abgeleitet.

Da Zephyr keine echte Wiederverwendung von Testfällen vorsieht, wird nicht sauber zwischen Testspezifikation (Testtemplate, Testrepository) und eingeplanter Testinstanz unterschieden. Eine Anpassung eines Testfalls wirkt sich so immer auf alle Einplanungen des Testfalls in Testzyklen aus. So ist das nur für kleine, einfache Vorhaben sinnvoll.

Testautomatisierung und Import von Testfällen

Zephyr ermöglicht eine Anbindung an eine Testautomatisierung über ein extra zu bezahlendes Add-On (ZAPI). Dies treibt die Kosten in diesem Einsatzszenario in die Höhe. Der Import von Testfällen wird ebenfalls über ein extra zu bezahlendes Add-On ermöglicht. Mit dem Jira Importer kann zwar eine CSV-Datei zur Anlage der Testfälle eingelesen werden, es können aber keine Testschritte importiert werden.

Xray für das Testmanagment mit Jira

Projektstruktur

Xray erlaubt sehr flexibel verschiedene Varianten der Projektstruktur. Xray unterscheidet hier ein logisch zwischen Testprojekt, in dem die Tests abgelegt sind und Anforderungsprojekt, das die zu testenden Anforderungen (z.B. Stories, Bugs, Requirements, Changes) enthält:

• Testprojekt und Anforderungsprojekt als ein Jira-Projekt („All-in-One“)
• Testprojekt als ein Jira-Projekt getrennt von einem oder mehreren Jira-Anforderungsprojekten („Separate my Requirements and Defects from Tests“)
• Testprojekt als ein Jira-Projekt getrennt von jeweils eigenen Jira-Projekten für Anforderungen und Defects („Separate Requirements, Test and Defects“)
• Testrepository als ein Jira-Projekt getrennt von einem Jira-Projekt für die Testausführungen und einem weiteren Jira-Projekt für das Anforderungsprojekt („Dedicated repository for Tests“)
• „Alles getrennt“: Anforderungen, Testrepository, Testausführung und Defects jeweils in eigenen Jira-Projekten („Completely separate“)
• Requirements Management außerhalb von Jira und nur Testprojekt in Jira („absolute Notlösung“)

Dies spiegelt sich dann auch in den Möglichkeiten des Reportings (Reports und Gadgets für Dashboards) wieder, das über mehrere Projekte hinweg funktioniert. Die Rechtevergabe ist nicht ganz so granular wie bei Zephyr, sondern wird über die „normalen“ Berechtigungen der Jira Konfiguration abgedeckt. Es wird daher empfohlen, ein vom Anforderungsprojekt getrenntes Testprojekt zu nutzen, um die Rechtevergabe unabhängig vom Entwicklungsprojekt durchführen zu können, sollte dies notwendig sein. Eine solche Konstellation verwendeten wir in den meisten Projekten, in denen Xray zum Zuge kam.

Testentitäten, Testplanung und Testausführung

Wie Zephyr erweitert Xray Jira um vordefinierte Issue Types, um die Testentitäten abzubilden. Nach der Installation der App stehen einige neue Typen zur Verfügung:

• Test – es gibt manuelle Tests, automatische Cucumber Tests und automatische Tests mit generischer Automatisierungsanbindung
• Pre-Condition – Vorbedingungen können so für mehrere Tests wiederverwendet werden, eine Xray-Besonderheit
• Test Set – fassen Tests zusammen, um sie in der Testplanung einfacher zu handhaben. Je nach Einsatzszenario können so Testsuiten oder auch nur sinnvolle Testpäckchen erstellt werden.
• Test Execution – zur Planung von Testzyklen
• Test Plan – zur Zusammenfassung von Testzyklen zu einem übergreifenden Testplan und für übergreifendes Reporting
• Sub-Test Execution – zur Verwendung einer Test Execution als Sub-Task im „Anforderungsprojekt“

Xray unterstützt das Konzept eines Testrepositories. Hier werden die Testfälle in Ordnern organisiert. Ein Testfall befindet sich genau an einer Stelle des „Repository-Baumes“. Alternativ (und auch zusätzlich) können Test Sets zur Strukturierung verwendet werden. Ein Testfall kann dabei mehreren Test Sets zugeordnet werden.

Bei der Testplanung sind zumindest Test Executions zu verwenden. Diesen werden Testfälle zugeordnet, wobei damit eine „Kopie“ des Testfalls als „Test Run“ angelegt wird (dies ist die einzige Testentität in Xray, die kein Jira Issue Type ist). Somit haben Änderungen der Testfälle erst einmal keine Auswirkung auf die eingeplanten Test Runs. Wird der Test Run für einen geänderten Testfall aufgerufen, erfolgt eine Abfrage, ob die Änderung übernommen werden soll. Alternativ kann mit der bisherigen Version weitergearbeitet werden.

Test Executions werden entweder manuell oder über die Anbindung einer Testautomatisierung automatisch ausgeführt, abhängig von der Art des Testfalls.

Testautomatisierung und Import von Testfällen

Xray bringt einige Schnittstellen zu Testautomatisierung und CI Tools mit und ist auch über eine REST API ansprechbar. Weitere Information sind in der Xray Dokumentation zu finden.

Xray erlaubt den Import, auch von Testschritten, aus CSV, JSON und Clipboard, sowie aus anderen Tests in der Xray Installation.

Xray bietet einige Gadgets, vordefinierte Reports und JQL-Erweiterungen, die die Arbeit mit den neuen Issue Types erleichtern.

TM4J für das Testmanagement mit Jira

Projektstruktur

In TM4J werden Tests zusammen mit den Anforderungen in einem Projekt gehalten. Dabei erlaubt TM4J jedoch, Testfälle aus anderen Projekten nicht nur zu kopieren, sondern auch zu referenzieren, so dass Änderungen nur in einem Projekt durchgeführt werden müssen. Folgende grundlegende Wiederverwendungsszenarien unterstützt TM4J:

• Testprojekt und Anforderungsprojekt als ein Projekt – keine Wiederverwendung von Testfällen über Projekte hinweg bzw. nur über Kopieren von Testfällen
• Testprojekt und Anforderungsprojekt als ein Projekt – Wiederverwendung von Testfällen über Projekte hinweg per Referenz von Testfällen
• Testprojekt und Anforderungsprojekt als ein Projekt – Nutzung eines der Projekte als Testrepository, aus dem die Testfälle referenziert werden.

TM4J bietet eine feingranulare Vergabe von Berechtigungen. Die Traceability ist frei konfigurierbar.

Auch TM4J bietet viele (noch mehr als Xray) Reports, Gadgets und JQL Erweiterungen. Auch Confluence Makros für Reporting und Dashboards in Confluence stehen zur Verfügung. Hier sieht man deutlich die Handschrift des Anbieters Adaptavist: TM4J ist sehr flexibel konfigurierbar.

Reports können projektübergreifend erfolgen. Dabei bleibt die Projektauswahl in der Reportparametrisierung über Reports hinweg erhalten, sodass „Reihen“ von Reports über dieselben Projekte gemacht werden können.

Testentitäten, Testplanung und Testausführung

TM4J nutzt keine Jira Issue Types für die Umsetzung der Testentitäten, sondern legt diese in einer eigenen Datenhaltung in Jira an. Es gibt Testpläne, Testzyklen und Testfälle. Diese können ähnlich flexibel zu Jira um weitere Attribute ergänzt werden. Jedoch stehen aufgrund der getrennten Datenhaltung eventuelle Erweiterungen über Custom Fields aus Jira Add-Ons für die Testentitäten nicht zur Verfügung.

Ähnlich wie Xray unterstützt TM4J das Strukturieren von Testfällen über Ordner. Dies ist auch für Testzyklen und Testpläne möglich.  Testfälle, Testzyklen und Testruns werden „unterhalb“ der Requirements-Issues (z.B. Stories, Bugs) angelegt. Sie sind ansonsten nur in der Ordnerstruktur des jeweiligen Testentität-Typs zu finden. Wie bei Xray können Testfälle nur genau einmal in der Ordnerstruktur platziert werden.

TM4J bietet zwei interessante Features, die je nach Lage der Anforderungen an das Testmanagement die Wahl auf TM4J fallen lassen:

• Versionierung: TM4J unterstützt das Versionieren von Testfällen. Bei der Einplanung kann so eine bestimmte Version eines Testfalls gezogen werden.
• Call-toTest: Hiermit ist die Verschachtelung von Testfällen möglich. Dabei können zudem Parameter definiert werden, die dann bei der Testausführung automatisch für das „Testskript“ so expandiert werden, dass für den Tester eine sequentielle Liste von Testschritten (ggf. mit expandierten Parametern) angezeigt (und protokolliert) wird.

Testautomatisierung und Import von Testfällen

TM4J bietet viele Schnittstellen, zur Testautomatisierung, eine REST API, zu eazyBI und ScriptRunner. Weitere Information zur Anbindung von Schnittstellen sind in der Dokumentation zu finden.

Fazit

• Zephyr für Jira war für meine Projekte bisher eine zu einfache Lösung. Ich vermute, dass die App bewusst so platziert ist, um die vom Anbieter ebenfalls angebotene Standalone Testmanagement Lösung nicht zu kanibalisieren.
• Xray hat für einige meiner Projekte gut gepasst. Insbesondere, weil es flexibel verschiedene Einsatzszenarien unterstützt und die Testentitäten als Jira Issue Types umgesetzt sind, was eine sehr gute Integration auch mit weiteren Apps ermöglicht.
• TM4J bot für die Projekte eine gute Lösung, die speziell die Versionierungsmöglichkeiten benötigten. Da TM4J jedoch die Testentitäten in einer eigenen Datenhaltung in Jira und nicht als Jira Issue Types umgesetzt hat, entstanden manche Herausforderungen im Zusammenspiel mit anderen Apps. Lösbar waren sie häufig, indem man mit der bekannten App Script Runner von Adaptavist Ergänzungen und Automatisierungen gescriptet hat.

Generell gibt es in agilen Umgebungen natürlich die Frage, inwieweit ein Testmanagement mit Jira in dieser integrierten Form überhaupt benötigt wird oder ein Testdriven Development mit einer ordentlichen Testautomatisierung überhaupt an Jira angebunden werden muss und nicht bereits selbst eine gute Reporting- und  Auswertebasis bietet. Beantwortet man die Frage mit dem Bedarf für ein Testmanagement mit Jira positiv, dann fällt meine Wahl meist auf Xray aufgrund der Flexibilität und der sehr guten Integration in die Jira Umgebung. Für spezielle Anforderungen greife ich bisher auf TM4J zurück.

Natürlich gibt es noch weitere Apps, die ein Testmanagement mit Jira unterstützen. Welches verwendet Ihr? Oder bleibt Ihr mit dem Testmanagement außerhalb von Jira? Habt Ihr überhaupt ein explizites Testmanagement für Eure agilen (oder klassischen) Projekte?