In diesem Artikel erfährst du, wie du deinen Bug gemäß unserer Regeln und Standards ordnungsgemäß dokumentierst. Damit Kunden einen Bug verstehen können, benötigen sie ausreichende Informationen in einem hochwertig dokumentiertem Bug-Report. Du findest detailliertere Informationen zu unseren Regeln in jedem Abschnitt dieses Artikels, aber hier ist eine schnelle Zusammenfassung unserer Anforderungen an Bug-Reports:

Dein erster Schritt im Bug-Formular sollte darin bestehen, das richtige Feature auszuwählen. Wenn du das richtige Feature nicht in der Dropdown-Liste findest, navigiere zurück zur Übersichtsseite des Testlaufs, gehe alle Feature-Beschreibungen durch und markiere sie als gelesen. Danach kannst du zum Bug-Formular zurückkehren und solltest nun alle Features in der Dropdown-Liste finden.

Nachdem du das Feature ausgewählt hast, wird dir das gesamte Bug-Formular angezeigt. Ein Formular für funktionale Fehler sieht zum Beispiel wie folgt aus:

Du solltest jedes Feld im Bug-Formular entsprechend unseren Qualitätsstandards mit den korrekten Informationen ausfüllen. Detaillierte Informationen zu jedem Feld und seinen Anforderungen findest du weiter unten.

Nur für funktionale Fehler gibt es ein zusätzliches Feld namens Schweregrad: Low, High und/oder Critical. Der Schweregrad zeigt die Priorität deines Berichts an und hängt von mehreren Faktoren ab. Informationen zu verschiedenen Schweregraden findest du in folgendem Artikel: Funktionale Fehler.

Das Feld Schweregrad wird für andere Bug-Arten nicht angezeigt.

Der Titel des Bug-Reports sollte das Problem zusammenfassen, sodass der Leser allein anhand des Titels eine allgemeine Vorstellung vom Bug bekommt. Um zu verstehen, worum es geht, sollte der Leser nicht den gesamten Bericht lesen müssen. Der Titel deines Bug-Reports sollte präzise, jedoch gleichzeitig nicht zu lang sein. Er sollte folgende Informationen enthalten: Was ist der Fehler, wo ist der Fehler aufgetreten und wann wird der Fehler ausgelöst? Wenn du also einen Titel für deinen Bug-Report schreibst, denke immer daran: Was? Wo? Wann?

Wenn du einen Bug im Titel beschreibst, beschreibe, was passiert, anstatt zu sagen, was nicht passiert. Dein Titel sollte niemals aussagen, dass etwas nicht funktioniert, da der Leser ansonsten keine Vorstellung darüber hat, was tatsächlich passiert.

Bug-Titel müssen das tatsächliche Problem widerspiegeln. Wenn der Fehler nur unter bestimmten Bedingungen auftritt, müssen diese Bedingungen im Titel enthalten sein. Wenn du zum Beispiel kein Ticket buchen kannst, da du ein Teenager bist, muss diese relevante Information im Titel enthalten sein.

Um einen aussagekräftigen Titel zu erstellen, versetze dich selbst in die Lage einer Person, welche die Website bzw. App noch nie getestet hat: Sie kann sich in der Regel nicht vorstellen, auf welcher Seite du dich befindest und was du genau gemacht hast. Lies deinen Titel aus dieser Perspektive, um zu sehen, ob du den Fehler verstehen würdest. Wenn du keine klare Vorstellung vom Fehler bekommst, passe den Titel an und wiederhole den Prozess.

Falsch: Fehler wird auf der Warenkorbseite angezeigt

Richtig: Nachdem der Benutzer auf den Button "Zur Kasse gehen" geklickt hat, wird auf der Warenkorbseite ein "Fehler 500" angezeigt.

Falsch: Der Benutzer kann kein Produkt in den Warenkorb legen

Richtig: „Unerwarteter Fehler“ wurde auf der PDP angezeigt, als der Benutzer eine „Größe“ auswählte und auf den Button „In den Warenkorb“ klickte.

Was an den obigen Beispielen falsch ist: Diese Titel könnten zu vielen möglichen Szenarien passen, weil sie zu abstrakt sind. Der Leser weiß nicht, welche Aktionen du durchführst und wie das System darauf reagiert. Daher muss er erst den gesamten Bericht lesen, um den Fehler zu verstehen und kann den Bug nicht auf einfache Weise von anderen unterscheiden.

Öffne die Seite, auf welcher der Fehler auftritt, und kopiere die URL aus der Adressleiste deines Browsers in das Feld URL des Bug-Report-Formulars.

Es muss eine gültige URL sein.

Bugs müssen reproduzierbar sein und sie benötigen eine detaillierte Schritt-für-Schritt-Anleitung, wie sie reproduziert werden können. Jeder Schritt sollte eine separate Aktion beschreiben.

Der erste Schritt muss den Zugriff auf die URL der Homepage des Kunden beschreiben (welche im Abschnitt "Zugang" in der Testlaufbeschreibung angegeben wurde). Sofern du statt einer Webseite eine mobile App testest, sollte der erste Schritt eine Anweisung zum Öffnen der App (mit der Angabe des App-Namens) enthalten. Alle weiteren Schritte sollten deine Aktionen vom ersten Schritt bis zu dem Punkt beschreiben, an welchem der Fehler auftritt – welche Buttons du drückst, welche Links du verfolgst und was du in Felder oder Formulare eingibst. Dein letzter Schritt sollte die Aktion beschreiben, welche du ausführst, um den Bug letztendlich auszulösen. Denke daran, dass "beobachten" keine Aktion ist, die vom Benutzer durchgeführt wird.

Deine Schritte sollten so allgemein wie möglich sein. Wenn dein Fehler unter bestimmten Bedingungen auftritt, z. B. nur auf einer bestimmten Produktübersichtsseite, für einen bestimmten Filter oder für eine bestimmte Eingabe usw., sollten diese speziellen Bedingungen auch in der Schrittbeschreibung erwähnt werden. Beschreibe in deinen Schritten bspw. aber nicht, dass eine spezifische Produktübersichtsseite aufgerufen oder ein bestimmtes Produkt in den Warenkorb gelegt werden muss, wenn das Problem bei jedem Produkt auftritt. Somit lässt sich der Bug besser vom Leser erfassen und er wird nicht von unwichtigen Details abgelenkt.

Stelle abschließend sicher, dass deine Schritte die geringste Anzahl von Aktionen enthalten, um den Bug auszulösen. Anhand deiner Schrittbeschreibung sollte der Leser problemlos in der Lage sein, den Bug zu reproduzieren.

Was ist falsch an dem obigen Beispiel?: Der erste Schritt muss eine Anweisung zum Zugriff auf die URL der Homepage enthalten, jedoch nicht nur die URL selbst. Der dritte Schritt ist nicht ausreichend detailliert und enthält zu viele Aktionen in einem einzigen Schritt. Die Schritte 2 und 4 sind überflüssig und nicht notwendig, um den Fehler zu verstehen.

Das tatsächliche Ergebnis ist eines der wichtigsten Felder eines Bug-Reports, weil du hier erklärst, was das Problem ist, und alle weiteren Details, die benötigt werden, um den Fehler zu verstehen.

Was tatsächlich passiert, nachdem du deiner Schritt-für-Schritt-Anleitung gefolgt bist, sollte so detailliert wie möglich beschrieben werden. Versuche hier sehr präzise und nicht zu allgemein zu sein. Statt z. B. nur zu schreiben, dass Produkte nach Anwendung der Sortierungsmethode X größtenteils in derselben Reihenfolge bleiben, solltest du stattdessen spezifische Beispiele für Produkte erwähnen, die sich nicht in der richtigen Reihenfolge befinden. Füge alle Informationen in diesem Feld hinzu, die für den Fehler relevant sind, z. B. weitere Bedingungen, Ausnahmen oder Ergebnisse anderer wichtiger Informationen, falls erforderlich. Strukturiere in diesem Feld deine Informationen, um den Leser zu unterstützen, deinen Denkprozess zu verstehen.

Ebenso darf das tatsächliche Ergebnis nicht dasselbe sein wie der Titel des Bug-Reports. Während der Titel eine Zusammenfassung des Problems ist, sollte das tatsächliche Ergebnis eine detaillierte Beschreibung davon enthalten und weitere Details wie Szenario-Informationen, Beispiele und Ergebnisse umfassen.

Falsch: Fehler wird auf der Warenkorbseite angezeigt, nachdem auf den Button "Zur Kasse gehen" geklickt wurde.

Richtig: Wenn der Benutzer einige Produkte in den Warenkorb gelegt hat und versucht, zur Kasse zu gelangen, ist dies nicht möglich. Beim Klicken auf die Schaltfläche "Zur Kasse gehen" im Menü auf der rechten Seite wird ein "Fehler 500 - Interner Serverfehler - Entschuldigung, etwas ist schiefgegangen" angezeigt.

Falsch: Der Benutzer kann kein Produkt in den Warenkorb legen, es wird ein Fehler angezeigt.

Richtig: Nachdem der Benutzer die Detailseite "Test IO - Produkt 1" geöffnet und die Größe 36 ausgewählt hat, wird nach dem Klick auf den Button "In den Warenkorb legen" ein Banner mit der Meldung "Unerwarteter Fehler" in der oberen rechten Ecke der Produktseite angezeigt. Das Produkt wird nicht in den Warenkorb gelegt.

In diesem Feld solltest du beschreiben, was bzw. welches Verhalten du nach dem zuletzt ausgeführten Schritt erwartet hast. Denke hierzu darüber nach, was normalerweise passieren sollte, wenn der Fehler nicht aufgetreten wäre und alles korrekt funktioniert hätte.

Denke daran, dass das erwartete Ergebnis sich vom tatsächlichen Ergebnis nicht nur durch ein paar Worte unterscheiden sollte. Stattdessen solltest du in diesem Feld hervorheben, was nach dem letzten Schritt zur Reproduktion des Fehlers hätte passieren sollen.

Falsch: Der Benutzer kann zur Kasse gehen.

Richtig: Nachdem einige Produkte in den Warenkorb gelegt wurden und auf den Button "Zur Kasse gehen" geklickt wurde, sollte der Benutzer korrekt zur Kasse weitergeleitet werden, wo er Versand- und Zahlungsinformationen hinzufügen und eine Bestellung aufgeben kann.

Falsch: Das Produkt sollte erfolgreich in den Warenkorb gelegt werden.

Richtig: Wenn die Größe: 36 für "Test IO - Produkt 1" ausgewählt und auf den Button "In den Warenkorb legen" geklickt wird, sollte das Produkt erfolgreich in der gewählten Größe in den Warenkorb gelegt werden. Der Benutzer sollte in diesem Prozess keine Fehler feststellen.

Um herauszufinden, welche Art von Anhang für deinen Bug-Report erforderlich ist und welche Regeln gelten, lies bitte den folgenden Artikel durch: Anforderungen für Anhänge zu Bug-Reports.

Für uns und unsere Kunden ist es wichtig, zu wissen, auf welchem Gerät der Bug aufgetreten ist. Hast du eine Webseite getestet, dann klicke zur Auswahl der Testumgebung auf das Browser-Symbol neben dem Gerät, welches du verwendet hast. Sofern du eine mobile App getestet hast, dann wähle das Gerät aus, welches du für den Test verwendet hast und auf dem die App installiert ist.

Du darfst nur die Geräte für Tests verwenden, die im Abschnitt der Testumgebungen aufgeführt sind. Darüber hinaus solltest du nur ein Gerät oder einen Browser auswählen, wenn du den Bug meldest und nur dafür Anhänge hochladen. Wenn du den Fehler auf anderen Geräten oder Browsern reproduzieren kannst, teile dies bitte in deinem tatsächlichen Ergebnis mit.

Die Auswahl der richtigen Testumgebung, auf welcher der Fehler auftritt, ist obligatorisch. Wenn du deinen Bericht einreichst, stelle sicher, dass du die richtige Testumgebung auswählst. Wenn du versehentlich den Bug mit der falschen Testumgebung eingereicht hast, lässt sich dies nachträglich noch korrigieren. Editiere hierzu die Testumgebung in deinem Bug-Report bevor der Teamleiter diesen überprüft. Wenn der Bug-Report die falsche Testumgebung enthält, wird er während der Überprüfung durch den Teamleiter abgelehnt.

Möchtest du mit einem Gerät testen, das nicht in der Liste der verfügbaren Geräte in deinem Profil aufgeführt ist? Sende uns einfach eine Anfrage über den Support-Chat und wir fügen dein Gerät deiner Liste hinzu, sofern es für unsere Kunden relevant ist.

Nachdem du deinen Bug eingereicht hast, kannst du alle Felder außer dem ausgewählten Bug-Typ noch bearbeiten. Ein Bug-Report muss von Anfang an alle relevanten Informationen inklusive Anhänge enthalten. Verwende die Bearbeitungsoption nur, wenn du einen kleinen Tippfehler gemacht hast oder deine Worte umformulieren möchtest, um die Qualität des Berichts zu verbessern.

Wenn dein Bug nur bei einer bestimmten Eingabe auftritt, verwende Begriffe, die auch von echten Benutzern verwendet werden würden und vermeide das Eingeben zufälliger oder irrelevanter Suchbegriffe beim Erstellen des Bug-Reports oder der Anhänge. Ein schlechtes Beispiel wäre die Verwendung eines Benutzernamens beim Erstellen eines Kontos in der Benutzeroberfläche des Kunden wie "asdsdfkg_lajsdh", da dies deinen Bug-Report unprofessionell aussehen lässt.