Skip to content

Was zeichnet einen guten Bugreport aus?

Und der Herr hob an und sprach also: “Zuerst sollest du den Heiligen Zündring ziehen. Dann sollest du zählen bis drei, nicht mehr und nicht weniger. Drei soll die Zahl sein, die du zählest, denn die Zahl zu zählen sei Drei. Vier sollest du nicht zählen, noch zähle auf Zwei, es sei denn, du schreitest hernach voran zur Drei. Fünf ist zu viel. Hast du dann erreicht die Drei, welche ist die dritte Ziffer unter den Ziffern, so werfe denn deine Heilige Handgranate Antiochias gegen deinen Feind, der in Meinen Augen ungehörig ist, und darob ausgelöschet werde.”

— Monty Python: Die Ritter der Kokosnuss

Da ich im Laufe meiner Projekte immer wieder mit Betatestern zu tuen hatte, musste ich zwangsläufig darauf achten das diese mir möglichst viele Informationen lieferten. Man kann davon ausgehen das Betatester “Paul” oder Betatesterin “Eva”, nunmal keinerlei Vorkenntnisse der Softwareentwicklung mitbringen. Das wiederrum heisst auch das sie nicht wissen, was ein Programmierer wissen muss in einem Report. Idealerweise hat man schon Tester, die in anderen Projekten Erfahrungen sammeln konnten.  Dies wird aber nur bei 1% aller Tester so sein.

Was wird führt für einen guten Bugreport überhaupt benötigt?

Jeder gute Bugbericht braucht genau drei Dinge.

  1. Schritte, mit denen man den Bug reproduzieren kann
  2. Was man zu sehen erwartet hatte, und
  3. Was man statt dessen gesehen hat

Aber wie trägt man nun einen Bug genau ein, als Beispiel möchte ich hier meinen Lieblings Bug Tracker nennen und zwar den Mantis Bugtracker.

Um euch mal die einzelnen Schritte eines Bugreports genaustens zu erklären habe ich einige Grafiken angefügt die mir dies erleichtern.

Wie trage ich einen Bug ein (Beispiel: Mantis Bugtracker)

Die Kategorie:

2009-02-14_174723

In diesem Bereich stehen die einzelnen Kategorien eines Projektes, wenn wir dies auf die Spieleindustrie auslegen dann haben wir eventuell  folgende Kategorie Möglichkeiten.

Beispiel für Kategorien (Hier aus einem Spieleprojekt)

2009-02-14_1804421

Ihr müsst nun festlegen und einschätzen wo dieser Fehler aufgetreten ist, z.b. habt ihr einen “Krakenden Sound” gehabt, also ist hier die Kategorie “Sound” natürlich richtig.

Die Reproduzierbarkeit:

2009-02-14_1755151

Vielfach ist es so das ihr, entweder einen absolut Reproduzierbaren Fehler gefunden habt, oder aber ihr habt einen Crash, der euch aus Heiterem Himmel aus dem Programm geworfen hat.

2009-02-14_183937

Hier habt ihr einen entsprechende Auswahl von Zuständen die sich auf die Reproduzierbarkeit eures Fehlers beziehen. Von immer (always) über nicht Reproduzierbar müsst ihr eine Einschätzung geben.

Grundsätzlich gilt, ein Bug der nicht Reproduzierbar ist, wird von keinem Gelöst (Gefixt). Versucht immer möglichst viele Informationen im Vorfeld zu merken. Die letzten 3 Schritte die ihr vor diesem Bug getan habt, denkt stark nach, was habe ich vorher gemacht, was ist das Resultat daraus.

Der Schwierigkeitsgrad:

2009-02-14_175527

Der Schwierigkeitsgrad des Fehlers kann im Punkt “Severity” festgelegt werden, Mantis Bug Tracker bietet eine größere Auswahl an, ich habe in vielen Projekten aber festgestellt das eine Gewichtung von A-C oder A-D vollkommen ausreicht.

Die Priorität:

2009-02-14_175540

Die Priorität wir meistens nicht vom Betatester festgelegt sondern von einem “Dispatcher” der die einzelnen Bugs gegentestet und entsprechend noch verbessert oder ergänzt. Dazu aber mehr in anderen Bereichen. Wenn ihr solch eine Auswahlmöglichkeit vorliegen habt, bedenkt ein Crash ist immer als “Hoch” (High) einzuschätzen, ein Textfehler ist immer  “Leicht” (Low) anzusehen. Klingt logisch, ist auch so. Es ist aber keine Aufgabe von euch eine richtige Einschätzung vorzunehmen.

Die Produkt Version:

2009-02-14_1756001

Hier habt ihr immer die Möglichkeit, eine Produkt Version einzutagen, das kann eine Nummer einer Betaversion sein, der aktuellste Patch, oder eben die ausgelieferte Release Version sein. Dies ist eine sehr wichtige Information, da es dem Entwickler zeigt, in welcher Version dieser Fehler aufgetaucht ist.

Eure Hardware- und Software:

2009-02-14_175618

Um bei Grafik oder Soundfehlern, order anderen Fehlern, schnelle Lösungen zu finden, ist es unermesslich wichtig das ihr eure Angaben dazu an den Entwickler liefert. Je besser hier die Angaben sind, so schneller kann ein Entwickler reagieren.

Die Summary:

2009-02-14_1756341

Die Summary ist sozusagen die Überschrift der Fehler Beschreibung, in diesem Bereich tragt ihr kurz eine Beschreibung des Fehlers ein.

Beispiel:

Mount: Beim Aufsteigen auf ein Mount , legt sich der Charakter quer auf sein Mount

oder

Es gibt einen Absturz beim Questgeber XY wenn man diesen Anspricht

Eure kurz Beschreibung sollte möglichst Eindringlich auf den Punkt kommen, so das man den Fehler direkt versteht.

Die Discrition: /Beschreibung

2009-02-14_175647

Hier beginnt der wichtigste Bereich eines jeden Bug Reports, die Beschreibung es ist enorm wichtig das ihr folgende Grundsätze beachtet:

Jeder gute Bugbericht braucht genau drei Dinge.

  • Schritte, mit denen man den Bug reproduzieren kann
  • Was man zu sehen erwartet hatte, und
  • Was man statt dessen gesehen hat
  • 2009-02-14_175700

    Steps to Reproduce:

    Wichtig für uns Entwickler sind die einzelnen Schritte zur Peproduktion eines Fehlers, anbei mal ein Beispiel wie so etwas aussehen kann/könnte.

    -> start game xy
    -> choose any char
    -> start a new sp or lan game
    -> teleport to [21;27;0;2831.601563;846.250000;99.666679;212.239578]
    -> accept the quest – tutorial xy
    -> find his son and kill the alphawolf
    -> go back to the runemaster and finished the quest
    -> have a look at the drop
    -> rotate the camera until you see the bug
    -> see the problem described above

    { 3 } Comments

    1. Sir Richfield | February 16, 2009 at 1:39 pm | Permalink

      Sag mal, der Text über Mantis – ist der über Google Translations gelaufen?

    2. admin | February 17, 2009 at 12:19 am | Permalink

      ^^ öhhh muss ich mir mal anschauen

    3. admin | February 17, 2009 at 12:21 am | Permalink

      Du meinst diesen Artikel?

      Nein ist von mir selber geschrieben worden…

      Meinst du einen anderen?

    Post a Comment

    Your email is never published nor shared. Required fields are marked *