Workflow zum Testen mit JIRA und Bonfire

von tinatigertech

Das im folgenden vorgestellte Testverfahren wird mit den kommerziellen Entwicklungstools JIRA und Bonfire von Atlassian durchgeführt. Diese werden mittlerweile in vielen Unternehmen weltweit eingesetzt, da die Lizenzen günstig und die Tools sehr gut für agile Softwareentwicklung geeignet sind.

Atlassian ist eine australische Softwarefirma die im Jahr 2002 von Mike Cannon-Brookes und Scott Farquhar in Sydney gegründet wurde, die sich aus Studienzeiten an der Universität von New South Wales kannten. Das Unternehmen machte 2009 einen Umsatz von AUD $58 Millionen und hat 20.000 Kunden weltweit. Atlassian ist Anbieter von Enterprise 2.0-Software.
JIRA ist das erste Softwareprodukt von Atlassian und seit 2002 auf dem Markt. Bonfire als ergänzendes Webseiten-Test-Plugin gibt es seit 2011. JIRA ist eine webbasierte Anwendung zur Fehlerverwaltung, Problembehandlung und operativem Projektmanagement. Primär wird JIRA für die Softwareentwicklung eingesetzt. Dort unterstützt es das Anforderungsmanagement, die Statusverfolgung und später den Fehlerbehebungsprozess. Der Name stammt vom ursprünglichen japanischen Namen für Godzilla, „Gojira“. Die Entwickler von JIRA wollten etwas mit Bezug zu Bugzilla und kamen so auf Gojira. Ausgesprochen wird es, der japanischen Lesart entsprechend, „Dschiera“ und nicht, wie vielfach fälschlich angenommen, „Dscheira“.

Eigentlich ist JIRA also für das Aufgabenmanagement gedacht. Vor allem wird in der Softwareentwicklung darüber das Bug-Management abgewickelt. Da Bugs häufig beim Testen gefunden werden, kann es Sinn machen, die Tests ebenfalls in JIRA abzubilden.

Hierbei handelt es sich mein eigenes Verfahren, das ich in folgendem Beitrag vorstellen will. Dabei werde ich erklären wie das Testen in JIRA funktioniert, wie es eingerichtet wird und was es für Vorteile hat.

1. Von UserStories zu Testcases

Zunächst werden aus vorhandenen UserStories Testcases für das Testen in JIRA erstellt.

Wie sollte ein Testcase aussehen?

Ein Testcase ist die kleinstmögliche Einheit in einer UserStory, wenn möglich nur eine Aktion des Nutzers. Er besteht aus einer Vorbedingung, einer durchzuführenden Aktion und einem erwarteten Ergebnis.

Beispiel:

Testcase: A reason is given why the login is in this particular context necessary
Pre-Condition:
User is not logged in
Action:
Check if next to login form a reason is given why the login is in this particular context necessary, incl. links to help articles.
Expected Result:
The reason is given and understandable, links to help are available.

2. Anlegen von Templates

Da die gleichen Tests oft mehrfach für verschiedene Testumgebungen, verschiedene Hardware oder mehrere Versionen der Software durchzuführen sind, lohnt es sich Templates dafür anzulegen, die sich dann bei Bedarf kopieren lassen.

In JIRA gibt es hierfür die Clone-Funktion. Man fasst zusammengehörige Testcases in einer Testreihe zusammen und legt diese als Subtasks eines Testreihen-Tasks an. Die gesamte Testreihe kann dann geklont werden.

Umbenennen der geklonten Testreihe

Leider wird von JIRA immer automatisch ein CLONE vor den Namen des geklonten Issues gesetzt. Dieses muss entfernt werden, ebenso ein evtl. eingesetztes TEMPLATE. Außerdem kann eine Versionsnummer hinzugefügt werden für die diese Testreihe gilt, im Beispiel 1.0.

Zuweisen der Testreihe an einen Tester

Nach dem Klonen der Testreihe kann diese einem Tester zur Bearbeitung zugewiesen werden. Um die Templates zu schützen kann man auch ein Sicherheitslevel einführen, sodaß die Templates nur für den Projektleiter zu sehen und zu bearbeiten sind und erst die geklonte Testreihe für alle Tester sichtbar gemacht wird.

Beispiel für 5 Templates für Testreihen

3. Einrichten der Testumgebung – Bonfire installieren

Bonfire ist ein JIRA-Plugin von Atlassian zum Testen von Webapplikationen direkt im Browser. Da Bonfire eine Browser-Erweiterung ist, kann man schnell Bugs berichten oder Verbesserungen vorschlagen, ohne die Web-Applikation, die gerade getestet wird, zu verlassen.

Das Bonfire-Plugin läßt sich direkt in JIRA unter MeinName -> GetBonfire installieren. Für jeden Browser muss es extra installiert werden (Firefox, Safari, IE..)

Der Login erfolgt entweder zuerst in JIRA oder direkt in Bonfire :

Server URL: Adresse des Unternehmens-JIRA

Username: wie in Jira

Password: wie in Jira

Anlegen von Templates in Bonfire

Um beispielsweise das Projekt, den Vorgangstyp, die Testumgebung u.a. nicht bei jedem Task neu anlegen zu müssen, können in Bonfire Templates erstellt werden.

Es wird empfohlen die folgenden 2 Templates anzulegen:

1. Template für Bugs

2. Template für Verbesserungsvorschläge (Improvement)

Wichtig für die Bugbehebung sind genaue Browserinformationen. Diese lassen sich durch die Angabe der folgenden Variablen auslesen:

– Browser information: {useragent}

– Current page title: {title}

– Current page URL: {url}

– Are cookies turned on? {cookies}

4. Durchführen eines Tests

Der Tester dem eine Testreihe zugewiesen wurde, öffnet den Task und dann den ersten Testfall. Dann führt er die folgenden 5 Schritte durch:

  1. Die Vorbedingung wird überprüft und gegebenenfalls hergestellt.
  2. Die Aktion wird durchgeführt.
  3. Wenn das erwartete Ergebnis erzielt wird, wird der Testfall als „passed“ geschlossen.
  4. Wenn der Test fehl geschlagen ist, wird er mit „failed“ gelöst und ein Bug erstellt.
  5. Das Einstellen eines Bugs erfolgt im besten Fall mit Bonfire (wenn eine Webseite getestet wird)

Die Lösungen „passed“ und „failed“ sind in JIRA nicht standardmäßig vorgesehen, können aber vom Administrator hinzugefügt werden.

5. Nutzen von Testsessions zum Protokollieren des Testvorgangs

Eine Test-Session dient dazu, alle zusammengehörenden Fehlermeldungen und auch die benötigten Arbeitszeiten zusammenzufassen. Dazu wird in JIRA ein Vorgang angelegt und eine neue Test-Session für diesen Vorgang eröffnet. Alle beteiligten Tester können diese Session in ihrem Webbrowser auswählen, alle gefundenen Fehler werden nun in der Session-Übersicht tabellarisch aufgeführt.

Dazu sind die folgenden Schritte nötig:

Testsession anlegen

Im Menü der Testreihe unter „Weitere Aktivitäten“ den Punkt „Create Test Session“ auswählen. Der Session einen Namen geben und einen Bearbeiter zuweisen. Sie erscheint dann im Task unter dem Punkt “Testing” und hat den Status “Created”.

Testsession starten

In der Testreihe unter „Testing“ läßt sich die soeben erstellte Testsession auswählen. In der folgenden Ansicht kann man die Session starten mit einem Klick auf “Start Session”.

Ansicht: Testsession ist gestartet

Ab sofort zeichnet die Testsession alle Aktivitäten des Testers auf

Arbeiten mit Sessions in Bonfire

In Bonfire läßt sich eine Session pausieren und erneut starten, wenn Pausen eingelegt werden möchten und die Uhr nicht mitlaufen soll. Außerdem merkt sich die Session alle erstellten Vorgänge.

Erstellen von Vorgängen in Bonfire

Beenden der Testsession

Wenn alle Testcases einer Testreihe abgearbeitet sind, kann die Testsession beendet werden.

Ansicht: Testreihe mit beendeter Testsession

6. Anlegen eines Dashboards zur Verfolgung des Testverlaufs

Vorteile:

  • Testfortschritt kann genau nachvollzogen werden
  • Fehlgeschlagene Tests lassen sich schnell auffinden und überprüfen
  • Auslastung der einzelnen Tester ist sichtbar
  • Nachvollziehbarkeit der Bearbeitung der erstellten Bugs
  • Bei der Aufteilung in Komponenten, die der unterschiedlichen Hardware zugeordnet sind, ist schnell ersichtlich welche Teile nicht funktionieren.
  • Bei je einem Dashboard pro Test-Team können Vergleiche der Testergebnisse durchgeführt werden.

Ein Kommentar zu “Workflow zum Testen mit JIRA und Bonfire”

  1. Vielen Dank für die Inspiration. Wir haben unsere Tests in den vergangenen Monaten nach dem hier beschriebenen Prinzip aufgesetzt und erreichen dadurch eine sehr hohe Transparenz bezüglich des Zustandes unserer Produkte. Das ist eine schöne Ergänzung zu der ansonsten eher unbekannten Releasereife von Features im Scrumprozess. Das Bugtracking und -management war schon davor in JIRA verankert, die Tests zu integrieren ein genialer Tipp. Mittlerweile verwalten wir ca. 2500 Usecases in JIRA und kombinieren daraus je nach Bedarf bis zu 4200 Testcases. Der gesamte Testprozess ist an Scrum gekoppelt, d.h. innerhalb der Sprintphasen prüfen wir die einzelnen Stories und verfassen direkt aus dem Sprintplanning heraus Use- und Testcases. Vollständigkeit und Präzision der Testscases bilden eine wichtige Grundlage für die Effizienz des Testverfahrens. Akzeptanzkriterien der POs, Featurespezifikationen sowie die unterschiedlichen Anforderungen der Stakeholder fließen mit ein und sind wichtige Bestandteile unserer Friendly User Tests. Die Testautomation mussten wir dafür leider aufgeben, da die hohe Releasedichte im agilen Umfeld nur bedingt ein zuverlässiges Fundament für effektive automatisierte Tests bietet. Unsere Abnahmetests erfolgen daher manuell. Wir erzielen dabei einen hohen Wirkungsgrad und reduzieren die Falsepositives auf ein Minimum. Laut Usability Guru Jakob Nielsen erzielt man die besten Resultate mit einem kleinen Testsetup und einer hohen Anzahl ein Testeinheiten: „The best results come from testing no more than 5 users and running as many small tests as you can afford.“ Im Zuge seiner Recherchen und Analysen formulierte Nielsen eine Formel zur Darstellung des Verhältnisses von entdeckten Usability Problemen zu der Anzahl von Testern: „N(1-(1-L)n) – where N is the total number of usability problems in the design and L is the proportion of usability problems discovered while testing a single user“. Demzufolge benötigt man mindestens 15 Tester, um alle Fehler zu finden. Der ideale Wert liegt bei fünf Testern, da diese ca. 80% der Fehler finden. Statt einem einzigen sehr aufwendigen Test, sollte man lieber zu einem iterativen Ansatz mit mehreren Tests in kleinerem Rahmen übergehen. Nichts anderes definiert Scrum für die Entwicklung.

Schreibe einen Kommentar