Wie man eine Bug-Tracking-Vorlage in Jira erstellt
Eine Bug-Tracking-Vorlage ist ein vordefiniertes Format zum Dokumentieren und Melden von Fehlern in der Softwareentwicklung. Eine Vorlage stellt sicher, dass wichtige Details konsistent erfasst werden, was das Nachverfolgen, Priorisieren und die Kommunikation im Team erleichtert.
Jira ist ein Issue-Tracking-Tool von Atlassian und wahrscheinlich eines der beliebtesten Bug-Tracking-Tools, das für das Projektmanagement in der Softwareentwicklung genutzt wird (insbesondere in agilen Umgebungen). Ich habe es in den letzten Jahren für viele Projekte verwendet, sowohl mit Scrum als auch mit Kanban, und finde es sehr vielseitig.
In diesem Artikel bespreche ich die Vielseitigkeit von Jira beim Bug-Tracking, die Anpassbarkeit und das Workflow-Management sowie die Verbesserung des Fehlermeldens mit Jira.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Egal, ob Sie für die Einrichtung der Jira-Workflows verantwortlich sind oder darüber Fehler melden – es schadet nicht, zu wissen, wie es funktioniert. Jira ist mehr als nur ein Tool zur Fehlermeldung, aber in diesem Artikel konzentrieren wir uns speziell auf die Nachverfolgung von Bugs und weniger auf das Management anderer Ticketarten.
Ein neues Projekt mit Jira Software einrichten
Wenn Ihr Projekt neu ist, müssen Sie zunächst das Jira-Projekt einrichten. Diese Aufgabe übernimmt normalerweise der Scrum Master oder Projektmanager, aber wenn sich Ihre QA-Rolle mit einer dieser Rollen überschneidet, könnte sie auch auf Sie zukommen. Das Ganze ist nicht kompliziert und sollte ohnehin nur einmal gemacht werden!
Die Anmeldung ist kostenlos, und für kleine Projekte mit weniger als zehn Nutzern können Sie den kostenlosen Plan verwenden. Falls Sie ein größeres Team haben oder erweiterte Funktionen benötigen, sollten Sie auf einen der kostenpflichtigen Pläne zurückgreifen. Ich gehe nicht auf die Details ein, aber bei Interesse können Sie die Jira-Preisseite besuchen.
Ich habe neue Projekte bislang nur zum Unterrichten angelegt, aber der Prozess ist sehr intuitiv. Sie können zwischen verschiedenen Projektarten für die Softwareentwicklung wählen:
Projektarten
- Ein Kanban-Projekt ermöglicht das Anlegen von Kanban-Boards. Sie können die klassische Vorlage mit den klassischen Phasen verwenden: To do, In Progress und Done.
- Scrum – Mit dieser Vorlage kann das Team seine Sprints und das Backlog nach dem Scrum-Framework verwalten.
- Bug-Tracking – Eine einfache Vorlage für das Nachverfolgen von Tickets, ohne dabei eine agile Methodik zu verwenden.
Alle Projekte lassen sich anpassen, um die Phasen, Übergänge und Status einzubeziehen, die das Projekt benötigt.
Für dieses Tutorial verwende ich die Scrum-Projektvorlage, damit Sie sowohl User Stories als auch Bugs im selben Projekt verfolgen können. Keine Sorge – alles, was ich zeige, lässt sich auch auf andere Projektarten anwenden!
Vorgangstypen
Die Standard-Vorgangstypen, die Jira anbietet, sind:
- Epic: In der agilen Entwicklung ist ein Epic eine übergeordnete Sammlung von User Stories und Aufgaben.
- Bug: Diesen Vorgangstyp nutzen wir in Jira, um gefundene Fehler und Defekte zu verfolgen. Auf sie konzentrieren wir uns im weiteren Verlauf des Artikels.
- Story: Eine User Story (die Beschreibung der zu entwickelnden und zu testenden Funktion oder Eigenschaft).
- Task: Üblicherweise verwendet zum Nachverfolgen einzelner Aufgaben oder To-Dos, zum Beispiel Recherchen zu einem neuen Testautomatisierungstool oder zum Aktualisieren der Dokumentation.
- Subtask: Das ist eine einzelne Aufgabe, die einem Teammitglied zugewiesen ist und als untergeordneter Vorgang zur oben genannten „Task“ gehört.
Wie bereits erwähnt ist Jira sehr vielseitig, und falls Sie einen eigenen Vorgangstyp benötigen, können Sie diesen jederzeit im Projekt anlegen.
Zum Beispiel habe ich an einem Projekt gearbeitet, in dem wir einen separaten Vorgangstyp für Verbesserungen hatten. Diese ähnelten User Stories, bezogen sich jedoch im Wesentlichen auf Verbesserungen bestehender Funktionen in der Anwendung.
Oder du kannst einen Vorgangstyp für Testfälle anlegen, aber dazu kommen wir später noch, wenn wir verfügbare Plugins und Jira-Integrationswerkzeuge behandeln.
Fehlerverfolgung mit Jira
Kommen wir zu dem, was uns Tester interessiert – Fehler melden und nachverfolgen. Jira ist zwar ein Projektmanagement-Tool und kein reines Bug-Tracking-Tool, aber wir als QA werden es wahrscheinlich sehr oft zum Melden von Fehlern benutzen 😁.
Workflow und Fehlerlebenszyklus
Der Standard-Workflow für Bugs (und für alle Vorgänge) sieht in Jira so aus:
Wenn ein Vorgang erstellt wird, hat er zuerst den Status 'Zu tun'. Danach kann der Vorgang, oder eben der Bug, in jeden der anderen Status verschoben werden.
Das Testmanagement-Team, der Scrum Master oder der Projektmanager sind üblicherweise dafür verantwortlich, eigene individuelle Workflows zu gestalten.
Der Workflow spiegelt den Fehlerlebenszyklus wider, den du im Projekt haben möchtest. Du kannst den einfachen Standard-Workflow beibehalten oder bei Bedarf auch komplexer gestalten. Ehrlich gesagt habe ich noch nie an einem Projekt gearbeitet, das nicht eigene, angepasste Status und Übergänge hatte.
Um den Lebenszyklus individuell anzupassen, musst du zu den Projekteinstellungen gehen, den Vorgangstyp "Bug" auswählen und auf 'Workflow bearbeiten' klicken.
Hier kannst du beliebige neue Status hinzufügen und bei Bedarf einen bestimmten Übergang auswählen. Hier ein Beispiel:
In diesem Fall hat ein neu angelegter Vorgang den Status 'Zu tun' und kann nur auf 'In Bearbeitung' verschoben werden. Bevor der Bug getestet werden kann, muss der Code überprüft werden. Das QA-Team kann ihn nach erfolgreicher Überprüfung im Status 'In QA' schließen. Natürlich können sowohl Code-Review als auch QA scheitern – dann wird der Bug wieder auf 'In Bearbeitung' zurückgesetzt.
Schritt-für-Schritt-Workflow-Erstellung
Ich gehe Schritt für Schritt durch, wie du vom ersten Workflow zum zweiten (oder zu jedem beliebigen, individuellen Workflow, der zu deinem Projekt passt) gelangst:
1. Klicke zuerst auf die Schaltfläche 'Workflow bearbeiten'
2. Um einen neuen Status hinzuzufügen, klicke auf einen der Status – diese sind in drei Kategorien aufgeteilt: 'Zu tun', 'In Bearbeitung' und 'Erledigt', jeder bekommt eine bestimmte Farbe zugeordnet. Du kannst selbst entscheiden, wo der Status am besten passt. Ich habe entschieden, dass 'Im Code-Review' und 'In QA'-Status immer noch zur Kategorie 'In Bearbeitung' gehören:
Du kannst auch mehrere 'Zu tun'-Status anlegen, zum Beispiel einen 'In Prüfung'-Status. Dies ist sinnvoll, wenn eine neue Funktion angelegt wird und der Product Owner oder Business Analyst noch Informationen ergänzen muss, oder das Team noch nicht final über Komplexität oder Story Points entschieden hat.
3. Nachdem du den neuen Status hinzugefügt hast, kannst du einen Übergang dafür definieren. Standardmäßig kann der Status von jedem anderen Status aus aktualisiert werden. Wenn du keine spezifischen Übergangsregeln willst, ist das in Ordnung. Ein durchdachter Workflow erlaubt es aber oft, Bugs und Vorgänge nur nach bestimmten Prozessschritten auf spezielle Status zu verschieben.
Im obigen Beispiel kann das QA-Team nicht mit der Überprüfung des Fixes beginnen, bevor ein anderer Entwickler den Code überprüft hat. Um diesen Übergang anzulegen, klicke auf die Schaltfläche 'Übergang' und gib die Details ein:
4. Du kannst natürlich auch bestehende Übergänge und Status löschen, wenn du alles zu 100% individuell gestalten möchtest.
5. Ein wirklich cooles Feature sind automatische Bearbeiter. Diese Funktion legst du auch innerhalb des Workflows fest, indem du einen Standardbearbeiter zuweist, wenn ein bestimmter Übergang für einen Vorgang durchgeführt wird (das ist übrigens auch ein wichtiges Argument für Issue-Tracking-Software).
Beispielsweise wird nach der Überprüfung eines Fehlers und seiner Verschiebung in den Status „In QA“ automatisch ein bestimmter Tester oder der Testmanager zugewiesen, der dann entscheidet, wer daran arbeitet. Genauso verhält es sich mit „In Bearbeitung“ und dem Entwicklungsteam. Neu erstellte Tickets können automatisch einem Projektmanager oder Product Owner zugeordnet werden, der sie anschließend im Backlog priorisiert. Das System ist sehr anpassbar, sodass Sie es genau auf die Anforderungen Ihres Teams zuschneiden können.
Auch wenn Sie nicht für die Konfiguration der Issue-Lebenszyklen verantwortlich sind oder keinen Zugang zu den Projekteinstellungen haben, können Sie den Workflow jedes Jira-Issues einsehen, indem Sie das Dropdown-Menü für den Status aufklappen:
Anzeigen von Issues in Jira
Wenn es sich nicht um ein Bugtracking-Projekt handelt, können Sie die aktuellen Tickets auf dem Kanban- oder Scrum-Board ansehen:
Dies dient nur zur Veranschaulichung; ich bezweifle, dass Sie jemals das Glück haben werden, einen Sprint nur mit einer User Story und einem einzigen Bug zu erleben 😅.
Wenn Sie auf ein Ticket klicken, werden Ihnen die Details angezeigt. Diese beinhalten unter anderem eine automatisch von Jira vergebene ID, einen Titel, eine Beschreibung, den Ersteller, die zugewiesene Person sowie alle Anhänge oder Kommentare, die Teammitglieder hinzugefügt haben.
Auch die Felder lassen sich anpassen, und ich zeige Ihnen später, worauf Sie in einem guten Bugreport achten sollten.
Zugewiesene Personen
Alle Jira-Tickets können einem bestimmten Teammitglied zugewiesen werden. Sie können Personen in Kommentaren oder in der Beschreibung erwähnen, indem Sie das @-Zeichen vor dem Namen verwenden.
Sie erhalten Benachrichtigungen, wenn Sie jemand taggt oder wenn ein Ihnen zugewiesenes oder von Ihnen gemeldetes Ticket aktualisiert wird. Sie können Issues auch „beobachten“. Sie werden benachrichtigt, sobald beobachtete Tickets aktualisiert werden – unabhängig davon, wer der Melder oder die zugewiesene Person ist.
Fehlermeldungen in Jira
Eine Anwendung mit wenigen Fehlern ist das Ziel aller, aber mal ehrlich: Tester freuen sich immer, wenn wir einen guten Bug finden.
Aber ein guter Bug ist nur so nützlich wie der Bugreport: Ein guter Fehlerbericht sorgt dafür, dass er mit möglichst wenig Hin und Her zwischen Test- und Entwicklungsteam behoben wird. Jira ist ein hervorragendes Tool zur Fehlerverfolgung. Habe ich das schon erwähnt? Es bietet viel Flexibilität.
Um ein neues Ticket zu erstellen, klicken Sie auf die große Schaltfläche „Erstellen“, woraufhin sich ein Dialog öffnet. Hier wählen Sie den Issue-Typ „Bug“ aus:
Ein guter Bugreport sollte eine aussagekräftige Beschreibung (in Jira oftmals „Zusammenfassung“ genannt) enthalten. Er sollte knapp, aber so detailliert sein, dass klar ist, worum es geht.
Fügen Sie in der Beschreibung alle relevanten Details hinzu. Sie können diese wie folgt klassisch strukturieren:
- Schritte zur Reproduktion
- Erwartetes Ergebnis
- Tatsächliches Ergebnis
Anschließend geben Sie weitere relevante Details zum Defekt an. Screenshots oder Videoaufnahmen sind immer sinnvoll, ebenso wie Protokolle oder spezielle Dateien, die während der Ausführung verwendet wurden.
In Jira können benutzerdefinierte Felder zu Tickets hinzugefügt werden. Ich persönlich trenne gerne die „Schwere“ (Severity) von der „Priorität“. Während „Priorität“ ein Standardfeld in Jira ist, kann man für die „Schwere“ ein eigenes Feld hinzufügen.
Weitere nützliche benutzerdefinierte Felder können sich auf das Betriebssystem beziehen – etwa ein Textfeld oder eine Dropdown-Auswahl mit voreingestellten Werten, z. B. die verwendeten Android- und iOS-Versionen beim Testen, der Browser, die Build-Nummer oder sonstige Informationen, die für die Nachverfolgung von Fehlern relevant sein können.
Um neue Felder hinzuzufügen, gehen Sie in die Projekteinstellungen, wählen Sie den Typ „Bug“ aus und entscheiden Sie, welches Feld Sie benötigen:
Testfälle in Jira
Das Letzte, worüber ich sprechen möchte, sind Testfälle. Die Jira-Software kann mit verschiedenen Testmanagement-Tools integriert werden, oder Sie fügen Atlassian-Erweiterungen und Add-ons hinzu, wie etwa Zephyr (früher mein Favorit) oder Xray. Wenn Sie einen Bug als Ergebnis eines fehlgeschlagenen Testfalls anlegen, kann der Test mit dem Bug verknüpft werden, was beim Verwalten von Bugs, Tests und der Testfalldurchführung sehr hilfreich sein kann.
Sie möchten mehr?
Jira kann ein großartiges Tool zur Fehlerverfolgung sein und den Entwicklungsprozess verbessern, da es viele Anpassungsmöglichkeiten bietet. Wenn es um Bugs geht, ist es besonders nützlich, weil Sie den Workflow so anpassen können, dass er dem gewünschten Lebenszyklus in Ihrem Projekt entspricht. Sie können Bugs mit Testfällen verknüpfen und benutzerdefinierte Felder auf eine Weise hinzufügen, die für Ihr spezifisches Projekt am sinnvollsten ist.
Für weitere Anleitungen wie diese abonnieren Sie den The QA Lead Newsletter.
