straX: Testmanagement mit Jira

Wo liegt eigentlich das Problem?

Unter straX verstehen wir bei PPI.X die Einheit aus methodischem Testvorgehen, die in den agilen Softwareentwicklungsprozess integriert ist. Durch die Nutzung des Tools wird das Team in seinen Testaufgaben unterstützt.
Es gibt viele andere Möglichkeiten, um straX umzusetzen. Für das Entwicklungsprojekt unseres Produkts Convo haben wir eine einfache Lösung entwickelt, die ich hier vorstellen möchte.
Bevor ich das tue, möchte ich eine Herausforderung benennen, die sich aus dem Rollenverständnis bei der Transformation hin zu agilem Projektvorgehen ergibt und die zu unserer Lösung geführt hat.

„Funktionierende Software ist das wichtigste Fortschrittsmaß.“

Das ist eines der agilen Prinzipien. Übertragen auf die Begrifflichkeit in unserem Entwicklungsprozess ließe sich das auch so ausdrücken: Das Feature (User Story, Use Case etc.) ist nicht fertig, wenn der Entwicklungs-Task abgeschlossen ist. Sondern: Das Feature ist fertig, wenn der Test vollständig gezeigt hat, dass es wie gewollt funktioniert und keine Nacharbeiten erforderlich sind.
Um diese Aussage treffen zu können, ist eine Abfolge miteinander verbundener Aufgaben zu erledigen:

• Ermittlung der notwendigen Testüberdeckung aus der Risikobewertung,
• Festlegung der Teststufe und Art der Testdurchführung,
• Planung und Steuerung der Erstellung automatisierter und manueller Testfälle,
  der Testdurchführung,
• der Abweichungsanalyse,
• der Fehlerbehebung und Fehlernachtests.

Alles Tätigkeiten, die klassisch durch die Rolle „Testmanager*in“ mit Verantwortung für den Testprozess ausgefüllt werden. Im agilen Entwicklungsvorgehen unserer PPI.X-Projekte existiert die Rolle Testmanager*in aber nicht!

„Das Team verantwortet die Qualität!“

Es stellt sich die Frage, wie der Testprozess so abgebildet werden kann, dass die Aufgaben und deren Status dem gesamten Team transparent sind. Das Team muss jederzeit sehen können, welche Testaufgaben noch umzusetzen sind, um die Features abzuschließen.

Die Wahl des Tools: verzichten lernen

Es liegt nahe, das Testmanagement in denselben Tools abzubilden, die bereits in den Projekten genutzt werden. Dabei ist nicht nur wichtig, dass der Testprozess durch das Tool unterstützt wird, sondern auch, dass die Verfolgbarkeit zwischen User Story und dem Ergebnis der Testdurchführung der zugehörigen Testfälle möglich ist, die Traceability. Manuelle und automatisierte Testfälle sollten an derselben Stelle gleichartig und nachvollziehbar dokumentiert sein und das alles möglichst kostengünstig, leichtgewichtig und straX ;-).
Spezialisierte Testmanagementwerkzeuge bieten eine Vielzahl komfortabler Funktionalitäten – die wir in den PPI.X-Projekten nicht brauchen. Ob kommerziell oder Open Source, als Stand-alone-Lösung oder Plug-in für Jira: Entweder sind die gewünschten Eigenschaften in der Nutzung durch das Team nicht oder nur zu hohen Kosten gegeben.
Als bester Kompromiss auf der Suche nach einer Lösung bot sich für uns Jira an, da es bereits in den PPI.X-Projekten eingesetzt wird und keine zusätzlichen Kosten verursacht.

Wie funktioniert das?

Die Stärke von Jira liegt in der Darstellung beliebiger Issues und Abhängigkeiten, also beispielsweise von Aufgaben und Unteraufgaben. Dashboards sorgen für Übersicht.
Für das Testmanagement wurden neue Issue-Typen in Jira konfiguriert: Test Aspect, Test Case, Test Run und Test Plan. Die Issues repräsentieren die Testaufgaben und enthalten alle Informationen.
Durch die Verlinkung der Issues miteinander entsteht die Traceability. Die Kette erstreckt sich von der Quelle (zum Beispiel einer User Story) bis zum Bug, der bei der Testdurchführung entdeckt wird. Quellen und Bugs müssen dabei nicht in Jira liegen, bei Convo wird dafür die Ticketverwaltung von GitLab eingesetzt.

Wie werden die Issues verwendet?

Jeder für das Testmanagement verwendete Issue-Typ verfügt über spezifische Informationen und Eigenschaften. Durch ergänzende Spielregeln ist festgelegt, welche Bedeutung die Eigenschaften haben und wie sie zu verwenden sind. Beispielsweise nach welchen Regeln Prioritäten vergeben werden.
So werden die Testaufgaben in den Issues abgebildet:

• Test Aspects beschreiben prüfbare Eigenschaften oder Leistungsmerkmale, die sich zum Beispiel einer User Story oder einem Use Case entnehmen lassen. Dabei wird beschrieben, WAS geprüft wird, und noch nicht WIE. Ziel sollte sein, alle testbaren Eigenschaften vollständig zu erfassen. Dadurch entsteht Transparenz zur erforderlichen und vorhandenen Testüberdeckung. Verlinkt wird der Test Aspect mit der Quelle.
• Im nächsten Schritt wird der Test Case erstellt, der einen oder mehrere Test Aspects prüft. Der Test Case enthält die konkrete Beschreibung des Testablaufs und der zu verwendenden Testdaten. Bei Convo sind viele Testfälle per Cucumber/Selenium automatisiert. Dann wird die Beschreibung aus dem Feature-File automatisch in den Test Case in Jira übertragen. Bei den manuellen Tests ist hier die Schritt-für-Schritt-Anleitung zur Testdurchführung enthalten.
• Die Dokumentation der Testdurchführung erfolgt im Test Run, der als Subtask zum Test Case das Ergebnis der letzten Testdurchführung dokumentiert, dem Test Run Status. Über die Verlinkungen wird der Test Run Status bis zur Quelle sichtbar.
• Der Test Plan bündelt die Test Cases, die zu einem Zeitpunkt durchgeführt werden. Im Test Plan werden die Testergebnisse der verlinkten Test Cases und der Test Runs dokumentiert.

Das ist – fast – schon alles!

Zu allen für den Test genutzten Issues existieren Dashboards, die eine Übersicht über den Status und Verlauf der Bearbeitung geben:

Durch die Dashboards werden die Testaufgaben zur Fertigstellung der Features für das Team sichtbar. So gilt zum Beispiel ein Test Aspect ungeprüft, der noch mit keinem Test Case verlinkt ist. Oder ein Test Case, der noch keinen Test Run Status hat, wurde noch nicht durchgeführt usw.

Unsere Erfahrungen

Bei der Entwicklung war von Beginn an klar, dass nicht alle Funktionalitäten umsetzbar sind, die spezialisierte Testwerkzeuge bieten.
Aus der gemeinsamen Nutzung in anderen Unternehmensteilen und für andere Verwendungszwecke ergeben sich Beschränkungen in der Modifizierbarkeit der Jira-Installation. Durch die weitgehende Begrenzung auf die Bordmittel von Jira ergeben sich weitere Einschränkungen im Bedienungskomfort, die für uns aber verkraftbar sind.
Im Projekt Convo haben wir die Erfahrung gemacht: Die Vorteile der Lösung überwiegen. Es bietet das, was wir benötigen – und nicht mehr.
Wie straX bei Convo benutzt wird, erfährst du zukünftig in diesem Blog.
Und vielleicht ist straX: Testmanagement mit Jira ja auch für andere agile Teams eine Lösung.