Skip to main content

Wählen Sie Ihre Region aus, um Inhalte für Ihren Standort zu sehen.

Wie man einen guten Fehlerbericht schreibt

Schritt-für-Schritt-Anleitung

Fehler isolieren

Der erste Schritt beim Schreiben eines Fehlerberichts ist es, genau zu identifizieren, was das Problem ist. Zu sagen etwas ist falsch ist nicht hilfreich, genau zu sagen, was falsch ist und wie man es reproduzieren kann, ist unbedingt erforderlich. Wenn Sie genau wissen, was falsch ist, und ein Beispiel des Problems zuverlässig reproduzieren können, haben Sie einen Fehler isoliert.

Überprüfen Sie, ob Sie die neueste Version verwenden

Fehlerberichte sollten auf dem neuesten Entwicklungsstand basieren. Wenn Sie eine freigegebene Version oder einen veralteten Build verwenden, aktualisieren Sie bitte auf die neueste Version und überprüfen Sie, ob der Fehler noch vorhanden ist oder nicht.

Überprüfen Sie, ob der Fehler bekannt ist

Bitte prüfen Sie, ob der Fehler, den Sie gerade feststellen, bereits in Ihrem Projekt in JIRA (https://support.infoniqa-hr.com/support) dokumentiert ist. Wenn er bereits dokumentiert ist, können Sie auf Vorgang beobachten  klicken, um alle Entwicklungen zu verfolgen. Wenn sich Ihr Fehler von anderen unterscheidet, die in JIRA aufgezeichnet wurden, erst dann klicken Sie auf Erstellen ... zum Erfassen eines neuen Vorgangs.

Jedes Problem separat erfassen

Wenn Sie mehrere Probleme haben, ist es unbedingt erforderlich, diese separat zu erfassen, damit sie leichter bearbeitet und verfolgt werden können.

Erstellen Sie einen neuen Vorgang

Melden Sie sich bei https://support.infoniqa-hr.com/support an und gehen Sie zur Startseite. Klicken Sie auf "Erstellen".
Es gibt eine Reihe von Anfangsfragen, die für die Einreichung eines Fehlerberichts verwendet werden - gezielte Antworten darauf ermöglichen uns für Sie schneller eine Lösung zu finden.

Titel bzw. die Zusammenfassung

Der Titel sollte das Problem so gut wie möglich beschreiben. Denken Sie daran, dass der Titel öfter gelesen wird als jeder andere Teil des Fehlerberichts.

  • Schlechter Titel: Veranstaltungen werden nicht angezeigt
    Dieser Titel ist nicht spezifisch genug, damit jemand ihn sich in einem Monat diesen ansehen und sich daran erinnern kann, worauf sich der Fehlerbericht bezieht.
  • Guter Titel: In der Veranstaltungssuche werden für Benutzer der Berechtigungsklasse ADMIN keine Veranstaltungen angezeigt
    Dieser Titel ist eine Verbesserung gegenüber dem vorherigen Titel, da er zumindest die Menge der lt. Vorgangsersteller betroffenen Benutzer definiert und wo das Problem auftritt. Damit kann dieser Vorgang später auch leichter wiedergefunden werden, sollte das Problem wieder auftauchen und Sie überprüfen müssen, ob der Fehler schon bekannt ist.

Nach dem Speichern des Vorgangs kann der Titel jederzeit verbessert oder angepasst werden.

Vorgangsdetails

Projekt

Die erste Frage ist, auf welches Projekt sich der Fehler bezieht. In der Regel ist ihr Projekt bereits vorbelegt.

Vorgangstyp

Der Typ des Vorgangs legt fest, ob es sich aus Ihrer Sicht bei dem Vorgang um einen Fehler, eine Frage, eine neues Feature bzw. Verbesserung oder Aufgabe handelt.

Priorität

Der Schweregrad ist der Grad der Auswirkung, den der Fehler oder der beschriebene Sachverhalt auf das Produkt hat.. Stufen Sie den Vorgang realistisch in Bezug auf Ihr Projekt und den laufenden Betrieb ein. Die aktuell definierten Prioritäten sind unten aufgeführt:

  • Blocker: KO-Kriterium, Projektechtbetrieb und/oder laufender Betrieb nicht möglich
  • Kritisch: Projektechtbetrieb und/oder laufender Betrieb nur mit wesentlichen Einschränkung möglich
  • Schwer: Schwerer Funktionsverlust.
  • Unkritisch: Projektechtbetrieb und/oder laufender Betrieb mit geringen Einschränkungen möglich bzw. Workaround ist vorhanden
  • Trivial: Kosmetisches/Optisches Problem, keine Einschränkung des Projektechtbetriebs bzw. laufenden Betriebs

Fälligkeitsdatum

Sollte der Vorgang bis zu einem gewünschten Datum erledigt sein, dann können Sie diese Information über die Angabe eines Fälligkeitsdatums an den Support weiterleiten.

Beschreibung

Schritte zur Reproduktion von Fehlern oder einer neuen Anforderung

Ein Fehlerbericht oder auch eine neue Anforderung erfordert klare Anweisungen, damit andere ihn konsistent reproduzieren können. Viele Fehler erfordern einige Experimente, um die genauen Schritte zu finden, die das Problem verursachen, das Sie zu melden versuchen. 

Ein guter Satz von Anweisungen gibt an, mit welchem Benutzer das Problem reproduziert werden kann und beinhaltet eine nummerierte Liste, die jeden Tastendruck oder jede Menüauswahl detailliert beschreibt. 

Es kann auch hilfreich sein, seine eigenen Anweisungen so zu testen, als ob jemand anderes sie ausprobieren würde.

Tatsächliches Verhalten

Beschreiben Sie im Gegensatz zum erwarteten Verhalten, was aktuell passiert, wenn der Fehler vorliegt. Oder wenn Sie eine neue Anforderung beschreiben, wie Sie diese jetzt lösen müssen.

Erwartetes Verhalten

Beschreiben Sie, was passieren sollte, wenn der Fehler behoben wurde. Bzw. beschreiben Sie, was Sie sich jetzt im Sinne einer neuen Anforderung an dieser Stelle erwarten würden.

Betriebssystem

Informationen zum Betriebssystem (bspw. Browser und Version) helfen Ihnen dabei, dass wir für Sie schneller eine Lösung  finden können.

Anhang

Jede Fehlerbeschreibung bzw. Beschreibung von Anforderungen und Aufgaben muss mit entsprechenden Bildschirmfotos (das gesamte Browserfenster sollte im Bildschirmfoto enthalten sein und nicht nur Ausschnitte), Logfiles (Keine Auszüge oder Screenshots von Logfiles, sondern das gesamte Logfile des Tages, an dem der Fehler oder das Problem reproduziert wurde), oder anderen Medien zur besseren Reproduzierbarkeit ergänzt werden. Dazu nutzen Sie die Möglichkeit, Anhänge an den Vorgang anzufügen. Fehlerbeschreibungen die nicht im Vorgang selbst beschrieben werden sondern nur in einem angehängten Dokument vorkommen, weisen wir ausnahmslos als Unvollständig  zurück, da dies für uns im Support nicht verarbeitbar ist.

Bitte achten Sie darauf, dass neben der Angabe in der Fehlerbeschreibung selbst auch im Bildschirmfoto erkennbar ist, welcher Benutzer im System angemeldet ist. Das ist sehr wichtig für die Reproduktion des Fehlers bzw. des Vorgangs. Bildschirmfotos können direkt im JIRA als Bild / Foto hochgeladen werden und dürfen nicht in ein eigenen Dokument (bspw. Word oder PDF) eingefügt werden.

Produkt Release

In welcher Version wurde das Verhalten beobachtet. Wird das Verhalten in mehreren Versionen/builds beobachtet, wählen Sie die jüngste Version aus.