Agiles Testen mit Jira – ohne Plugins oder Tools

Die Arbeit mit Jira macht Spass und zwar auch zum Testing. Dabei ist es aus meiner Sicht nicht unbedingt nötig, ein Testing-Plugin oder sonstige Zusatzsoftware zu verwenden – zumindest nicht beim agilen bzw. Embedded Testing. Wer als Tester im Team eng mit der Entwicklung zusammenarbeitet und auf ein kompliziertes Setup eines Testtools verzichten möchte, kommt sehr gut mit dem einfachem Jira zurecht. Ich zeige euch, wie es geht.

Jira Setup und Umgang mit Bugs

Das Setup ist sehr einfach: So wie die Entwickler an eine Story ihre Entwicklungs – Subtasks anhängen, hänge ich als embedded Tester einfach einen Test – Subtask an die entsprechende Story:

Story mit Test-Task und Bug-Task

Der Subtask „Manuelles Testing“ wird von mir bearbeitet, sobald alle Entwicklertasks auf Done sind oder der Entwickler sagt, dass die Story bereit ist zum Test. Wichtig ist hier nur, sich notfalls durch Rückfragen zu versichern, dass die Funktionalität auf einer Testumgebung deployed ist. Der Hauptzweck des Testtasks an der Story ist, die Story zu blockieren, damit die Story nach Abschluss aller Entwickertasks nicht automatisch auf den Status „Done“ wechselt!

Finde ich nun einen Bug, welcher direkt mit der Story zusammenhängt, dann wird an der Story ein Bug-Subtask erfasst. Das sieht dann so wie der Bug-Subtask im Screenshot aus, welcher „in Progress“ ist. Das führt automatisch dazu, dass die zugrundeliegende Story erst auf „Done“ wechseln kann, wenn alle storybezogenen Bugs korrigiert wurden.

Weiterhin kommt es öfters vor, dass beim Test einer Story Bugs gefunden werden, die nicht direkt mit der zu testenden Story in Zusammenhang stehen oder sich als Feature herausstellen. In dem Fall wird ein Bug oder eine neue Story im Backlog erfasst, welche dann wiederum im Refinement überarbeitet und daraufhin für einen späteren Sprint priorisiert werden können. Alternativ könnte sich der Tester mit dem Entwickler absprechen, dass der entsprechende Bug oder das Feature trotzdem im Rahmen der getesteten Story korrigiert werden – dass je nach Dringlichkeit und Aufwand. In diesem Fall sollte jedoch der PO informiert werden.

Abschliessend muss hier erwähnt werden, dass es sich bei diesem Setup um einen sehr agilen Ansatz handelt. Der Fokus wird dabei klar auf Testausführung und Fehlerfindung gelegt, zu dessen Gunsten die Dokumentation stark in den Hintergrund gerückt wird. Konkret werden nur Bugs wirklich dokumentiert. Der erfolgreiche Test einer Story ist dadurch dokumentiert, dass der Testtask auf Done gezogen wurde. Für mehr Dokumentation können natürlich im Testtask beliebig viele Kommentare hinterlassen werden.

Drei Levels der agilen Testdurchführung

Im ersten Abschnitt bin ich bereits darauf eingegangen, dass der Task «Manuelles Testing» hauptsächlich dazu dient, die Story zu blockieren. Das wird beim Blick in die Beschreibung des Testtasks deutlich:

Inhalt vom Test-Task

Meine Test-Tasks haben keine Beschreibung! Diese ist auch gar nicht nötig, denn ich orientiere mich an einem Testvorgehen mit drei unterschiedlichen Detaillierungslevels, welches ich täglich selbst anwende. Dabei muss für jede Story das erste Level zwingend ausgeführt werden und das zweite Level sollte berücksichtigt werden. Das dritte Level darf wenn immer möglich zur Anwendung kommen, ist aber nicht für jeden Typ von Story möglich und bedingt gewisses Know How des Embedded Testers.

Level 1 – Akzeptanzkriterien abtesten

Das erste Level ist einfach, klar nachvollziehbar und entspricht dem explorativen Ausführen von Testfällen basierend auf fest definierten Akzeptanzkriterien. Daher handelt es sich aus meiner Sicht bei diesem Level um ein strukturiertes Vorgehen. Hier ein Beispiel einer Storybeschreibung mit Akzeptanzkriterien:

Storybeschreibung mit Akzeptanzkriterien

Als Beispiel, warum das erste Level sehr strukturiert ist, nehmen wir das erste Akzeptanzkriterium aus der Storybeschreibung des Screenshots: „AD-Gruppe xxx vorhanden“ wird abgetestet. Bei Verwendung eines Testtools würde dieses Akzeptanzkriterium im Gegensatz zum hier beschriebenen Ansatz per copy-paste in einen Testfall übernommen werden. Im Testfall würde somit folgendes stehen:

Das Resultat dieses Beispiel-Testfalls ist exakt gleich wie beim explorativen abtesten der Akzeptanzkriterien. Abgesehen von der Dokumentation des Testschritts wird das gleiche gemacht, wodurch auch die gleichen Fehler gefunden werden. Sobald der Testtask auf «Done» gezogen wird, ist somit davon auszugehen, dass mindestens alle Akzeptanzkriterien erfolgreich abgetestet wurden. Das ersetzt die fehlende Dokumentation der einzelnen Testschritte.

Testtask auf Done = Mindestens die Hauptanforderungen der Story wurden erfolgreich umgesetzt

Eine der Voraussetzungen für dieses Testlevel ist, dass die Story Akzeptanzkriterien enthält. Dazu kann der Tester einen Beitrag leisten, indem er aktiv am Refinement mitarbeitet und notfalls Akzeptanzkriterien einfordert oder selbst welche vorschlägt. Während dem Test vom Level 1 wird konkret folgendes gemacht:

• Jedes Akzeptanzkriterium wird in der Implementierung untersucht, hinterfragt und wenn nötig mehrfach in verschiedenen Konstellationen abgetestet.
• Bei unklaren Akzeptanzkriterien wird je nach Unklarheit der PO und/oder ein Entwickler konsultiert, um Klarheit zu schaffen.
• Ist ein Akzeptanzkriterium nicht erfüllt, wird dies mit dem Entwickler besprochen und / oder ein neuer Bug - Subtask eröffnet.

Level 2 - Studieren der restlichen Storybeschreibung / Kommentare / allfällige Requirementsbeschreibung im Wiki

In diesem Level werden alle Informationen herangezogen, welche neben den Akzeptanzkriterien existieren. Manchmal stehen bereits in der Storybeschreibung Informationen, welche in den Akzeptanzkriterien nicht erwähnt aber trotzdem relevant sind. Weiterhin können Kommentare an der Story, verlinkte Stories, Wiki-Einträge oder alle sonstigen schriftlich festgehaltenen Informationen herangezogen werden, in welchen die Story behandelt oder tangiert wird. Ziel ist das Finden von Fehlern, um am Ende eine höhere Qualität zu erreichen.

Der Vorteil, dies im zweiten Level zu überprüfen ist, dass ich nach dem ersten Level bereits mit dem Thema und der Implementierung vertraut bin. Alle zusätzlichen Informationen werden hier explorativ überprüft und hinterfragt. Im weiteren Verlauf entspricht die Vorgehensweise im zweiten Level der Vorgehensweise im ersten Level.

Level 3 - Der Blick nach Rechts, Links und in die Tiefe

Im dritten Level wird ebenfalls explorativ getestet, jedoch unabhängig von irgendwelcher schriftlich festgehaltenen Dokumentation. Es handelt sich um den erfahrungsbasierten und technischen Teil der Story-Tests. Diese Stufe ist erst seriös durchführbar, wenn der Tester mit dem Testobjekt sehr vertraut ist und bereits eine gewisse Zeit im entsprechenden Thema engagiert ist. Folgende Fragen kann man sich beim Durchführen des dritten Levels stellen:

• Ist mir etwas Spezielles während der ersten zwei Levels aufgefallen?
• Gab es ein seltsames Verhalten, welches ich vertieft untersuchen möchte?
• Ist es sinnvoll, allfällige zusätzliche Umsysteme anzuschauen? Zum Beispiel: Was wird in der Datenbank abgelegt, hat das Event den richtigen Inhalt, lohnt sich ein Blick auf die Verarbeitung im Server etc.
• Gab es in einer früheren Story eine Ausnahmesituation, welche einen Einfluss auf die aktuelle Story haben könnte?

Im dritten Level entsteht eine gewisse Wahrscheinlichkeit für neue Stories, wenn zum Beispiel Spezifikationslücken gefunden werden, welche erst im Rahmen der Implementierung aufgefallen sind. Diese werde als neue Stories festgehalten und dem PO kommuniziert, so dass er die neuen Stories entsprechend priorisieren und für das Refinement einplanen kann.

Fazit

Beim agilen Testen mit Jira sind zusätzliche Test-Plugins oder eine zusätzliche Testmanagement-Software nicht unbedingt nötig. Der hier vorgestellte Ansatz des Testvorgehens mit drei unterschiedlichen Detaillierungslevels gibt eine Idee, wie ein Embedded Tester vorgehen kann, um seine User Stories möglichst effizient und umfassend zu testen.

Voraussetzung für dieses Vorgehen ist ein hohes Mass an Vertrauen innerhalb des Scrum Teams sowie zu weiteren Stakeholdern. Es muss für jeden klar sein, dass ein Testtask auf Done für eine hohe Testabdeckung nach bestem Wissen und Gewissen steht. Qualitativ hochwertige und funktionierende Software wird somit höher gewertet als Dokumentation – ganz im Sinne der Werte des agilen Manifest. Somit steht mehr Zeit für die Testausführung zur Verfügung, was automatisch zu einer höheren Anzahl qualitativ hochwertiger Fehler sowie zu mehr Spass bei der Arbeit führen dürfte ?