Die Anatomie eines guten Fehlerberichts

Veröffentlicht: 2020-12-16

Seit fast anderthalb Jahrhunderten bezeichnen Ingenieure kleine Fehler in Maschinen als „Fehler“. Heutzutage werden "Bugs" sowohl für Hardware- als auch für Softwareprobleme in Computern und Gadgets verwendet. Computerfehler gibt es schon seit geraumer Zeit und mit ihnen kamen auch die Fehlerberichte.

Der erste Computerfehlerbericht wurde am 9. September 1947 von Grace Murray Hopper dokumentiert. Sie berichtete, dass eine echte Motte zwischen den Relaiskontakten im Harvard Mark II-Computer steckte. Der Fehler wurde in das Computer-Logbuch aufgenommen.

Mehr zum ersten Fehlerbericht finden Sie hier.

Seitdem sind Fehlerberichte ein wichtiger Bestandteil des gesamten QS-Prozesses. Sie bleiben das Hauptwerkzeug für die Meldung von Fehlern in Programmiercodes.

Dieser Artikel behandelt, was in einem guten Fehlerbericht enthalten sein muss. Es wird auch einige Beispiele für gute und schlechte Fehlerberichte geben, einschließlich einer kurzen Analyse jedes einzelnen.

Was ist ein Fehlerbericht?

Was ist ein Fehlerbericht @ 2x

Bei der Website-Entwicklung ist ein Fehlerbericht das Hauptwerkzeug, mit dem angezeigt wird, dass ein bestimmter Code nicht wie erwartet funktioniert. Es gibt viele verschiedene Beispiele für „Bugs“, um nur einige zu nennen:

  • Eine Website stürzt ab, weil zu viele Systemressourcen verwendet werden
  • Bilder erscheinen auf bestimmten Browsern oder Geräten seltsam
  • Ein Webstore zeigt für einige Produkte falsche Preise an
  • Eine Funktion entspricht nicht den Clientanforderungen

Der Hauptzweck eines Fehlerberichts besteht darin, dem Entwicklungsteam die Reproduktion des vom QA-Team gemeldeten Problems zu ermöglichen. Es ist wichtig, über alle erforderlichen Informationen zu verfügen, um das Debuggen und Beheben zu vereinfachen.

Fehlerberichte werden nicht nur verwendet, um Probleme zu melden, sondern auch um neue Funktionen und Verbesserungen vorzuschlagen . Daher gelten die meisten Richtlinien, was ein guter Fehlerbericht enthalten sollte, auch für Vorschläge.

In Verbindung stehender Artikel: So entwickeln Sie einen Qualitätssicherungsplan für Ihre WordPress-Website

Was sollte ein Fehlerbericht enthalten?

Was-sollte-ein-Fehler-Bericht @ 2x enthalten

Ein guter Fehlerbericht muss genaue Informationen zu dem aufgetretenen Problem enthalten. Dazu müssen die folgenden Elemente vorhanden sein, wie in der Vorlage, die wir hier bei DevriX verwenden. Bei Devrix basiert die Vorlage für Fehlerberichte auf diesen Elementen. Es wurde nachgewiesen, dass sie genügend Informationen zu den aufgetretenen Problemen liefern.

  • Titel - Dies sollte als kurze Zusammenfassung des Problems dienen. Es ist wichtig, dass der Titel spezifisch für die Art des Problems ist. Es ist das erste, was ein Entwickler sieht.
  • Status - Dies ist ein Indikator für den Status des Fehlerberichts. Abhängig von der verwendeten Verwaltungssoftware (wie Jira, Asana, Trello, Mantis usw.) kann es verschiedene Arten von Statuen geben. Einige Beispiele:
    • Zuzuweisen - Wenn noch nicht festgelegt ist, wer die Probleme im Bericht untersucht.
    • In Bearbeitung - Wenn ein Entwickler an der Behebung des gemeldeten Fehlers arbeitet. Dieser Status wird auch verwendet, wenn ein Update gerade getestet wird.
    • Vollständig - Ein Zeichen dafür, dass der gemeldete Fehler behoben wurde.
  • Priorität - Dies zeigt die Dringlichkeit eines gemeldeten Fehlers im Vergleich zu anderen Aufgaben und Problemen an. Die Priorität eines Fehlers hängt vom Schweregrad eines Fehlers ab, da er die Auswirkungen auf das getestete System misst. Die häufigsten Prioritäten sind:
    • Kritisch - Wird für Probleme verwendet, bei denen alle anderen Aktivitäten eingestellt werden müssen und alle Anstrengungen auf die Lösung der Situation konzentriert sind. Dies ist auf die Tatsache zurückzuführen, dass solche Probleme einen großen Einfluss auf das Projekt haben, für das sie gemeldet werden, und zu Verlusten für das Unternehmen führen können.
    • Hoch - Wird für Probleme verwendet, die eher früher als später behoben werden sollten. Sie haben keine so großen Auswirkungen, aber wenn es keine kritischen Probleme gibt, sollten sie so schnell wie möglich gelöst werden.
    • Mittel - Wird für Probleme verwendet, die keinen großen Einfluss auf die Kernfunktionalität haben. Es wäre gut, wenn sie gelöst würden. Solche Probleme müssen nach denen mit höherer Priorität behoben werden.
    • Niedrig - Wird verwendet, wenn der gemeldete Fehler geringfügig ist und keine Auswirkungen auf die Kernfunktionalität hat. Es könnte ein grammatikalischer Fehler in einem Blog-Beitrag sein oder die falsche Farbe für eine Schaltfläche.
  • Schweregrad - Wird verwendet, um den Grad der Auswirkung des gemeldeten Fehlers auf das getestete System anzuzeigen. Die häufigste Klassifizierung für den Schweregrad eines Fehlers lautet:
    • Kritisch - Eine Kernfunktionalität funktioniert nicht oder die gesamte Software funktioniert nicht.
    • Major - Eine oder mehrere grundlegende Funktionen sind vom Fehler betroffen. Aus diesem Grund liefert die getestete Software nicht die gewünschten Ergebnisse. Im Gegensatz zu Fehlern mit kritischem Schweregrad gibt es Funktionen, die wie beabsichtigt funktionieren.
    • Moderat - Es gibt keine Auswirkungen auf die Kernfunktionen der getesteten Software. Eine oder mehrere Komponenten sind betroffen, was zu inkonsistentem Verhalten führt.
    • Geringfügig - Die Auswirkungen auf die getestete Software sind gering.
    • Trivial - Fehler mit diesem Schweregrad wirken sich nicht auf die Funktionalität der Software aus. Dies können geringfügige visuelle Fehler, fehlende Übersetzungen, eine nicht funktionierende Bestätigungsmeldung usw. sein.
  • Fehlerdetails - Die Details enthalten wichtige Informationen darüber, wo das gemeldete Problem auftritt. Die folgenden Informationen sollten enthalten sein (obwohl verschiedene Organisationen möglicherweise unterschiedliche (Fehler-) Details benötigen):
    • Der Browser, in dem der Fehler aufgetreten ist (am besten auch die Version)
    • Das Betriebssystem - Es könnte ein Problem sein, das nur unter Windows auftritt. Dies schließt auch mobile Betriebssysteme wie Android, iOS und PadOS ein
    • Der Zweig - Dies ist für unveröffentlichte Updates (neue Funktionen oder Updates, die andere gemeldete Fehler beheben). Der Zweig enthält nur bestimmte Commits, die für ein Feature relevant sind. Dies geschieht, damit eine Änderung die Arbeit anderer Personen am selben Projekt nicht beeinträchtigt
    • Version - Wenn die getestete Software eine Desktop- oder mobile Anwendung ist. Es ist ratsam, die Version anzugeben, in der der Fehler gemeldet wurde.
  • Fehlerbeschreibung - Der QS-Spezialist muss eine genaue Erklärung des beobachteten Problems sowie die zur Reproduktion des Problems erforderlichen Schritte bereitstellen. Der Spezialist sollte auch beschreiben, wie das erwartete Ergebnis tatsächlich aussehen sollte. All dies ist wichtig, damit das Entwicklungsteam versteht, worum es geht, welche Aktionen ausgeführt werden müssen, um es zu reproduzieren, und wie das richtige Verhalten aussehen sollte.
  • Anhänge / Screenshots - Mit einem Anhang / Screenshot kann der Spezialist sehen, was und oft wo das Problem liegt. Es kann dem QS-Spezialisten auch die Schritte zur Verfügung stellen, die ausgeführt wurden, um das Problem auszulösen.
  • Kommentare - Der Kommentarbereich wird im Allgemeinen nicht verwendet, wenn ein neuer Fehlerbericht erstellt wird. Es ist jedoch wichtig, ein paar Worte darüber zu teilen, was in den Entwicklerkommentaren (und den folgenden Kommentaren) enthalten sein muss, wenn eine Fehlerbehebung an die gesendet wird QA-Team zum Testen. Entwickler müssen die folgenden Elemente enthalten:
    • Link zum Commit, das das Update enthält.
    • Erklären Sie, was das Update bewirkt.
    • Wenn Einrichtungsschritte ausgeführt werden müssen, ist es wichtig, diese zu erläutern.
    • Fügen Sie alle Screenshots / Screencasts hinzu, die das Update in Aktion zeigen.
    • Fügen Sie alle Notizen hinzu, die der QS-Spezialist beim Testen des Updates berücksichtigen muss.

Verwandte Ressourcen : Qualitätssicherungsarbeit ist ein wesentlicher Bestandteil der Arbeit an jeder Website. Aus diesem Grund hängt das Durchlaufen der langen und detaillierten Testphase, das Beheben von Fehlern und Regressionen und das Stabilisieren der Plattform für den Start davon ab, wie viel die Website kosten wird.

Schreibaufgaben für Vorschläge und neue Funktionen

Während der Durchführung von QS-Tests kommen erfahrene Tester in der Regel auf Ideen zur Verbesserung des Projekts. Ebenso müssen Projektbesitzer und Projektmanager Kundenanfragen (für Funktionen, Korrekturen, Verbesserungen) erhalten, die mit dem Entwicklungsteam geteilt werden müssen.

Im Gegensatz zu Fehlerberichten besteht das Ziel der Aufgaben "Vorschläge" und "Neue Funktionen" darin, Kundenanforderungen oder Verbesserungsvorschläge zu erläutern, die das Projekt verbessern können (z. B. die Implementierung eines Leistungsupdates, indem eine Funktion hinzugefügt wird, die eine bessere Interaktion mit den Benutzern ermöglicht , usw).

In beiden Fällen ist es wichtig, eine klare Beschreibung der zu implementierenden Funktion bereitzustellen:

  • Neue Funktionen, die vom Kunden benötigt werden - Es ist wichtig, dass der Projektbesitzer / Projektmanager versteht, was der Kunde benötigt, alle bereitgestellten Modelle überprüft und zusätzliche Details bespricht. Sobald klar ist, was der Kunde möchte, ist es einfacher, dem Entwicklungsteam zu erklären, was er tun muss.
  • Vorschläge - Es ist wichtig, eine klare Vorstellung vom gesamten Projekt zu haben und wie die vorgeschlagene Funktion es verbessern wird. Auf diese Weise wird es einfacher, die Idee und die damit verbundenen Vorteile zu erklären.

Gute und schlechte Fehlerberichte: Beispiele

Haftungsausschluss : Die folgenden Beispiele stammen aus einem QS-Kursprojekt, an dem der Autor teilgenommen hat. Ziel ist es, die Fehler zu analysieren, die in den Berichten gemacht wurden, und wie sie vermieden werden können.

Beispiel 1 :

Fehlerbeispiel 1

Hier ist ein Beispiel für einen gut geschriebenen Fehlerbericht. Es enthält alle oben diskutierten Attribute.

Es gibt jedoch ein Problem: Der Titel liefert keine genaue Vorstellung von dem gemeldeten Problem. Das fehlende Produktbild kann sich an einer beliebigen Stelle im getesteten Webshop befinden.

Ein besserer Titel ist "Fehlende Produktbilder im Abschnitt" Personen, die diesen Artikel gekauft haben, haben auch gekauft "". Auf diese Weise hätte das Entwicklungsteam anhand des Titels selbst eine Vorstellung davon, worum es in dem Bericht geht.

Beispiel 2 :

Fehlerbeispiel 2

Dies ist ein Beispiel für einen insgesamt schlecht geschriebenen Fehlerbericht. Die Hauptprobleme bei diesem Beispiel sind:

  • Der Titel ist nicht spezifisch, wo genau der fehlende Preis ist
  • In der Beschreibung wird nicht angegeben, wo genau das Problem beobachtet wurde.
  • Das erwartete Ergebnis erklärt nicht das richtige Verhalten.

Schlecht geschriebene Fehlerberichte zwingen das Entwicklungsteam dazu, unnötig Zeit damit zu verbringen, herauszufinden, wo das Problem liegt und wo sich das gemeldete Problem befindet. Das Team muss häufig den QS-Spezialisten, der den Fehler gemeldet hat, bitten, fehlende Details zu klären.

Beispiel 3 :

Fehlerbeispiel 3

Dies ist ein gutes Beispiel für einen ordnungsgemäß geschriebenen Fehlerbericht. Es gibt dem Entwicklungsteam eine klare Vorstellung davon, wo das Problem liegt und wie es reproduziert werden kann.

Ein kleines Problem mit diesem Bericht besteht darin, dass das gemeldete Problem den Testprozess nicht tatsächlich stoppt, was bedeutet, dass der zugewiesene Schweregrad und die zugewiesene Priorität falsch sind. Wenn der QS-Spezialist das Problem besser untersucht hätte, wäre ihm aufgefallen, dass eine Problemumgehung vorliegt.

Diese Problemumgehung hätte den Abschluss des Kontoregistrierungsprozesses ermöglicht. Es ist von großer Bedeutung, ein Problem zu untersuchen, bevor es gemeldet wird, damit keine wichtigen Details ausgeschlossen werden und der richtige Schweregrad und die richtige Priorität zugewiesen werden können.

Abschließend

Ein gut geschriebener Fehlerbericht der QAs ist hilfreich, damit das Entwicklungsteam versteht, was das Problem ist und wie es gelöst werden soll. Denken Sie dazu immer an Folgendes:

  • Der Titel des Fehlerberichts muss das gemeldete Problem zusammenfassen.
  • Geben Sie genaue Details an - die Plattform, auf der das Problem beobachtet wird, den Browser (für Webanwendungen), den Zweig, in dem das Problem beobachtet wird.
  • Geben Sie eine klare Beschreibung des gemeldeten Problems an.
  • Stellen Sie sicher, dass die Wiedergabeschritte korrekt sind.
  • Schreiben Sie auf, wie das erwartete Verhalten aussehen soll, im Gegensatz zu dem, was zum Zeitpunkt der Berichterstellung tatsächlich beobachtet wird.
  • Denken Sie daran, die entsprechende Aufgabenpriorität und den entsprechenden Schweregrad zuzuweisen.
  • Fügen Sie alle relevanten Dateien hinzu - Screenshots, Screencasts, Protokolle usw.
  • Fügen Sie zusätzliche Informationen hinzu, die dem Entwicklungsteam bei der Lösung des Problems helfen könnten.