So arbeiten wir - mit effizienten QA Prozessen zur digitalen Exzellenz Hier gehts zum Beitrag!
Read time: ca. 9 min
Bugreport

So schreibt ihr Bugreports richtig und effektiv für Entwickler:Innen

Janina

Ein guter Bugreport hilft dem Entwicklerteam enorm, um gezielt Verbesserungen an der Anwendung vorzunehmen. Durch diese Reports wird es den Entwickler*innen außerdem ermöglicht eine Einordnung der Dringlichkeit der Bugs vorzunehmen. Diese Reports werden während des Testings einer App oder einer anderen digitalen Software verfasst und bieten ausführliche Informationen über die auftretenden Bugs.

In diesem Beitrag zeigen wir euch, worauf es bei einem guten Bugreport ankommt und welche Fehler ihr besser vermeiden solltet, um dem Entwicklerteam die Fehlerkorrektur so einfach wie möglich zu machen.


Warum überhaupt ein Bugreport?

Während des Testings einer App oder einer anderen Software werden Bugreports von den Tester:Innen erstellt, um dem Entwicklerteam am Ende ein ausführliches Reporting liefern zu können. Mit Hilfe der Bugreports können diese die Anwendung dann bestenfalls so korrigieren, dass der User bei der Nutzung auf keinerlei Anwendungsprobleme trifft.

Doch wie müssen diese Bugreports aufgebaut sein? Was muss in diesen Reports enthalten sein? Ist jeder Bug eine Barriere für den User?

All diese Fragen, werden wir euch nun beantworten.

 

Klarer und präziser Titel

Ein guter und aussagekräftiger Bugreport beginnt bereits beim Titel. Ein guter Titel sollte den Entwickler:Innen einen ersten Ausblick auf das Problem geben. Sind die wichtigsten Informationen dort bereits enthalten, können Entwickler*innen den Bug gleich priorisieren. Ein effektiver Bug-Titel sollte somit wie folgt aufgebaut sein:

<Bereich der App>: Kurze Beschreibung des Problems

Ein Beispiel:
Check-Out:  Zahlungsvorgang bricht beim Tappen auf „Bezahlen“ ab

Folgende Dinge, solltest du im Titel lieber vermeiden:

  • Jegliche Arten von Nebensätzen, halte dich kurz
  • Keine wertenden Aussagen und nutze keine verstärkenden Adjektive wie z.B. „sehr“
  • Die Erwähnung einzelner Geräte oder OS-Versionen (dies gehört eher in die Beschreibung)
  • unpräzise Formulierungen wie „verhält sich falsch“ oder „fehlerhaft“
  • zu lange und ausführliche Titel


Typ des Tickets festlegen

Bei Bugtickets unterscheiden wir zwischen drei Arten von Tickets: Bug, Improvement und Performance Tickets.

Als Bug werden alle funktionalen Fehler bezeichnet, sprich alles wo die Funktionalität nicht mehr gegeben ist.

Performance und Improvement Tickets haben dagegen einen non-funktionalen Charakter, d.h. etwas funktioniert zwar, aber einfach nicht gut oder weniger gut als es eigentlich sollte.

 

Ausführliche Beschreibung des Problems

Diesen Bereich kannst du in 3. Schritte unterteilen:

  • Bereichs- & Funktionsbeschreibung

    Nenne zu Beginn nur wo das Verhalten zu finden ist und welche Funktion betroffen ist. Hier kannst du auch bereits erste inhaltliche Eingrenzungen treffen wie z.B. „im eingeloggten Zustand […]“.

  • Beschreibung des Verhaltens

    Nutze kurze Sätze. Schreibe im Passiv („Beim Tappen auf den Login CTA wird ein Pop up geöffnet“). Wäge relevante technische Konsequenzen ab und nimm sie im Ticket auf (hat das Verhalten zum Beispiel Auswirkungen auf andere Bereiche der App?

  • Technische Eingrenzung

    Einschließlich, sowie ausschließlich, auch wenn alle Geräte betroffen sind. Sprich alle Touchpoints an. Projektspezifische Eingrenzung („alle Apps sind betroffen“). Tritt ein Fehler nur auf bestimmten Geräten auf, gehe auf diese nochmal genauer ein und nenne die verschiedenen Geräte.

Bei der Beschreibung des Problems darfst du ruhig etwas mehr ins Detail gehen. Beschreibe den Bug hier so genau wie nur möglich in ganzen Sätzen. Dabei solltet ihr auf folgende Punkte achten:

  1. Nehmt euch die W-Fragen zur Hilfe (Wer, Was, Wann…usw)
  2. Kläre gleich zu Beginn die Ausgangssituation (Im Bereich XY tritt das Problem XY auf)
  3. Nenne auch Besonderheiten (wenn der Bug z.B. nur unter bestimmten Umständen/Geräten etc. auftritt)

Beschreibe hier auch, was du versucht hast, um den Fehler einzugrenzen, dies kann den Entwicklern helfen bestimmte Ursachen auszuschließen)

 

Erwartetes Ergebnis

Hier teilst du den Entwickler:Innen mit, welches Ergebnis du eigentlich erwartet hättest. Diese Information kann dem Entwicklerteam helfen zu verstehen, warum wir das bemerkte Verhalten für einen Fehler halten.

 

Reproduktion des Fehlers

Damit die Entwickler:Innen den Bug auch selbst noch einmal prüfen können, schreibe deine Schritte auf, die den Bug hervorrufen. Nummeriere die Schritte durch und versuche jeden Schritt einzeln darzustellen. Sollte der Fehler nur unter bestimmten Bedingungen im Testing auftreten verweise in der Anleitung darauf.

 

Account Daten

Musstest du dir für den Test einen Account erstellen, dann gib die verwendeten Daten zu dem Zeitpunkt, an dem der Bug auftrat, an. Achte aber unbedingt darauf, dass du niemals sensible Daten preisgibst. Solltest du dir darüber unsicher sein sprich vorher am besten mit deinem Testmanager (falls vorhanden) oder deinem Team. Beim Web-Test solltest du außerdem immer die URL einfügen.

Workspace-Tester

 

Bug nach Prioritäten einstufen

Die Einstufung des Bugs nach Priorität ist einer der wichtigsten Schritte beim Erstellen eines Bugreports. Die Prioritätsstufe ist abhängig davon, wie starken Einfluss der gefundene Bugs auf die Kundenerfahrung und die Zufriedenheit der User nimmt. Wie schwerwiegend das Problem ist, definieren Tester:Innen meist mit Hilfe ihres Wissens über die zu testende App.

Wir unterscheiden hier zwischen folgenden Auswahlmöglichkeiten:

  1. Blocker (Bug, der eine Veröffentlichung verhindert, z.B. Login funktioniert nicht)
  2. Critical (Hauptfunktionen funktionieren nicht oder nur eingeschränkt)
  3. Major (schwerwiegende Fehler, die aber die generelle Funktionalität und Nutzbarkeit nicht beeinflussen)
  4. Minor (eher kleinere Fehler, die nicht dringlich sind, da sie die Hauptfunktionen nicht einschränken)
  5. Trivial (ein eher oberflächlicher/geringfügiger Fehler)
  6. Cosmetic (kleine Anzeigefehler, die dem User auf den ersten Blick nicht auffallen)

 

OS Versionen

Auch die Angabe der Software auf dem Gerät, auf dem der Fehler auftritt, ist wichtig für das Entwicklungsteam, um diesen entsprechend zu korrigieren. Gib daher immer die OS Version an, über die das getestete Gerät aktuell verfügt.

 

Devices

Damit die Entwickler:Innen nachvollziehen können auf welchen Geräten die Fehler auftreten, empfehlen wir immer mindestens 6 verschiedene Geräte anzugeben, auf denen derselbe Bug auftritt. Tausche dich damit mit deinem Team aus oder nimm weitere Geräte in den Test auf, um möglichst viele Geräte festzuhalten.

 

Reproduzierbarkeit der Fehler

Hier gibst du einen Hinweis darauf, ob die Fehler sich immer reproduzieren lassen, ob sie nur ab und an auftreten oder sogar nur einmalig.

 

Anhänge einfügen

Wenn möglich füge an den Bugreport mindestens einen Screenshot oder eine Screen Aufnahme hinzu. So lässt sich der Bug visualisieren und besser nachvollziehen. Diese kannst du dann noch beschriften, wenn nötig. Auch die Benennung des Screenshots solltest du anpassen.

Stürzt die App ab, kannst du einen Crashlog anfügen.

Effektiver-Burgreport

 

Mit dieser Hilfestellung gelingt es euch nun hoffentlich einen guten Bugreport zu verfassen.
Und mit ein klein wenig Übung, geht es dann auch sicher von ganz allein. Also orientiere dich bei deinen nächsten Bugreport einfach an diesem Beitrag und du wirst dem Entwicklerteam mit Sicherheit einen sehr guten Report schreiben können!

Du bist bereits Profi im Bugreports schreiben und willst dein Können unter Beweis stellen? Dann schau gerne mal auf unserer Karriereseite vorbei! Wir suchen aktuell noch Apptester:Innen und Test Analyst:Innen.