Warum ein einfaches „Es funktioniert nicht“ nicht ausreicht?

Jeder, der jemals in der IT gearbeitet hat, hat sicherlich Kommunikationsprobleme zwischen Programmierern und Testern oder in anderen Fällen erlebt. Im Gespräch mit Programmierern kann man viele Anekdoten über Fehlerberichte und Rückmeldungen hören, die sie erhalten haben. Als Tester in einer Drupal-Agentur sehe ich dieses Problem von der anderen Seite, aber ich verstehe das Entwicklungsteam. Wenn ich eine Aufgabe aus den Tests zurückgebe, möchte ich oft einfach schreiben: „Es funktioniert nicht!“ Allerdings sind Situationen, in denen tatsächlich gar nichts funktioniert, ziemlich selten. Sie sollten glauben, dass, wenn ein Programmierer seinen Code zum Testen freigegeben hat, er sicher ist, dass er für ihn funktioniert und er zumindest einige der grundlegenden Pfade in seiner Umgebung überprüft hat. Deshalb sollten wir versuchen, dem Entwickler so viele Informationen wie möglich über den Fehler oder Bug zu geben, den wir gefunden haben.

„Es funktioniert nicht!“

Ein Bericht oder Ticket, das nicht genügend Informationen enthält, ist nutzlos, da es dem Entwickler nicht ermöglicht, den Fehler nachzubilden und somit das Problem nicht schnell zu lösen. Im Allgemeinen würde ich empfehlen, das Prinzip zu beachten, dass es besser ist, zu viel zu schreiben als zu wenig. Natürlich ist es auch wichtig, ein gewisses Maß an Zurückhaltung zu wahren und nicht zu übertreiben. Im Folgenden werde ich mehrere Dinge präsentieren, die es wert sind, in einem Fehlerbericht enthalten zu sein.

Titel 

Eine kurze, aber präzise Beschreibung der Art des Fehlers, z. B. falsche Validierung im Kontaktformular.

ID

Eine Nummer oder eine Zeichenfolge, die es jedem ermöglicht, sich unmissverständlich auf ein bestimmtes Ticket zu beziehen. Heutzutage müssen wir uns dank der Verwendung von Bug-Trackern oft keine Sorgen mehr darüber machen, da es für jede Aufgabe und jedes Ticket automatisch generiert wird.

Name 

Wenn die Person, die den Fehler gefunden hat, ihren Namen und ihre Details angibt, kann jeder dies diskutieren und mögliche Zweifel am Bericht klären (hoffentlich gibt es nicht viele davon).

Codeversion 

Eine Angabe der Version des Codes, auf dem die Aufgabe getestet wurde. Abhängig von der Unternehmenspolitik kann es sich zum Beispiel um einen Namen einer bestimmten Programmversion, den Namen des Branches oder das Testdatum handeln. Es ist wichtig, klar anzugeben, welche Version den Fehler enthält, da nicht jede Version ihn haben könnte.

Priorität 

In den meisten Fällen bedeutet Priorität den Zeitrahmen, in dem ein bestimmter Fehler behoben werden sollte. Oft wird es mit einer Skala dargestellt, wie „kritisch, hohe Priorität, normale Priorität und niedrige Priorität“. Sie können die Priorität eines bestimmten Fehlers abschätzen, indem Sie mehrere Faktoren berücksichtigen:

• wie schnell der Fehler behoben werden sollte,
• inwieweit er die Funktionalität eines gesamten Projekts beeinträchtigt,
• wie oft der Fehler auftritt,
• betrifft dieser Fehler eine neue Funktionalität oder etwas, das bereits von Ihren Benutzern verwendet wird. 

In diesem Fall ist die Priorität des Fehlers das Ergebnis dieser Faktoren, dargestellt auf einer Skala wie kritischer Fehler, schwerwiegender Fehler, normal, niedrige Priorität, Vorschlag. Natürlich können wir auch eine separate Kategorie für jeden dieser Faktoren zuweisen und sie in Tickets beschreiben – dies variiert von Unternehmen zu Unternehmen. Es ist jedoch wichtig, die gemeldeten Fehler zu kategorisieren.

Voraussetzungen 

Wenn vor dem Test bestimmte Maßnahmen ergriffen werden mussten oder Bedingungen erfüllt sein müssen, bevor die Nachbildung des Fehlers möglich ist, sollten Sie diese in Ihrem Ticket angeben. Zum Beispiel tritt der Fehler nur auf, wenn Sie ein Benutzerkonto erstellen und diesem die Rolle eines Editors zuweisen.

Testumgebung 

Es gibt Situationen, in denen ein bestimmter Fehler nur bei einer bestimmten Hardwarekonfiguration auftritt. Daher ist es entscheidend, ausführliche Details zur Hardware anzugeben, auf der der Fehler gefunden wurde, ihr Betriebssystem, Ihren Browser, alle Software, die den Betrieb des Programms beeinflussen könnte, Bildschirmauflösung und so weiter.

Fehlerbeschreibung/Schritte zur Reproduktion des Fehlers 

Natürlich reicht die kurze Beschreibung eines Fehlers im Titel nicht aus; Sie müssen das Problem auch auf die klarste und präziseste Weise beschreiben. Sie können mit einer kurzen Einführung beginnen, die den Fehler erklärt; das Wichtigste hier ist jedoch, alle Schritte zu beschreiben, die uns zur Entdeckung des Fehlers geführt haben. Sie sollten keine Beschreibungen wie „Ich habe die Fenster gewechselt“ oder „Ich habe einige Daten eingegeben“ verwenden, sondern genau beschreiben, was Sie geklickt haben und welche Daten Sie in die Felder eingegeben haben, da möglicherweise das Eingeben bestimmter Daten den Fehler verursacht. Wenn Sie eine Webanwendung testen, sollten Sie die URLs der Sites angeben, die Sie zur Fehlerfindung geführt haben.

Aktuelles Ergebnis 

Alles, was nach Abschluss aller Schritte passiert ist, die es Ihnen ermöglichten, den Fehler zu finden, sollte ebenfalls zuverlässig beschrieben werden. Denken Sie daran, zu vermeiden, Dinge zu schreiben wie „Und dann erschien ein Fehlerfenster“. Natürlich sollten Sie solche Informationen aufnehmen, wenn sie passierten, aber vergessen Sie nicht hinzuzufügen, welche Art von Fehler es war. Auch wenn es Ihnen nichts sagt, könnte es dem Entwickler tatsächlich helfen, die Ursache des Problems zu finden.

Erwartetes Ergebnis

Sie haben die Schritte beschrieben, die zur Entdeckung des Fehlers führten, beschrieben, was Sie gesehen haben, und es scheint, dass nichts anderes hinzugefügt werden kann. Tatsächlich ist dies sehr oft ausreichend; es gibt jedoch Situationen, in denen die Erwartungen in Bezug auf das Problem nicht so offensichtlich sind. Deshalb sollten Sie immer daran denken, klar zu formulieren, was Sie von einer bestimmten Aufgabe erwarten. Es ermöglicht allen, mögliche Unterschiede im Verständnis der Funktionsweise des Systems zu erklären und zeigt klar, was behoben werden muss.

„Präsentation – besser als tausend Worte...“

Zweifellos ist eine der besten Methoden, um Fehler zu melden, sie direkt dem Entwickler zu zeigen. Lassen Sie ihn sich vor Ihren Bildschirm setzen und zeigen Sie ihm Schritt für Schritt, wie der Fehler reproduziert werden kann. Als Autor des Codes weiß er, worauf er achten muss, wenn der Fehler auftritt, und wo er zusätzliche Informationen darüber finden kann, was passiert ist. Neben einer Fehlermeldung sollte er auch in der Lage sein, andere Indikatoren zu bemerken, die zeigen, dass etwas nicht wie vorgesehen funktioniert. Sicher, oft haben wir einfach nicht die Gelegenheit, Fehler direkt zu zeigen, aber Sie können immer versuchen, eine attraktive Alternative zu finden, die unsere Arbeit erleichtert, auch wenn es keine direkte Präsentation ist. Wenn Sie wissen, dass der gefundene Fehler nicht einfach zu beschreiben und eher komplex ist, versuchen Sie, Ihren Bildschirm während des Tests aufzuzeichnen. Es wird sicherlich helfen, das Problem zu verstehen. Wenn der Fehler nicht sehr komplex ist, versuchen Sie zumindest, einen Screenshot hinzuzufügen und den Fehlerort zu markieren. Viele Menschen auf der Welt sind visuelle Lerner und sie werden den Fehler besser verstehen, wenn sie ihn sehen. Dank dessen, selbst wenn sie es nicht schaffen, den Fehler auf ihrem Gerät zu reproduzieren, werden sie wissen, wie er in Ihrer Umgebung aussah.

Werkzeuge, die die Fehlermeldung unterstützen

All die oben genannten Elemente können auf viele verschiedene Arten gemeldet werden: mündlich, in einem Kalkulationswiege, E-Mail usw. Es ist jedoch auch wichtig, dieses Problem später zu verfolgen. Daher verwenden die meisten Unternehmen Software, um dies zu unterstützen. Nachfolgend finden Sie eine kurze Liste von Lösungen, die bei der Auswahl eines solchen Werkzeugs in Betracht gezogen werden sollten:

• Jira (kommerziell),
• Bugzilla (Open Source),
• Mantis (Open Source),
• Redmine (Open Source),
• Trac (Open Source),
• Stryka (kommerziell),
• LeanTesting (kostenlos, aber kostenpflichtige Komponenten),
• FogBugz (kommerziell).

Zusammenfassung

Zusammenfassend möchte ich Ihnen einige grundlegende Regeln und Prinzipien geben, die beim Melden von Fehlern beachtet werden sollten:

• denken Sie daran, sich klar und präzise auszudrücken, damit der Entwickler den Fehler leicht nachbilden kann,
• beschreiben Sie alle Symptome, die auf ein Fehlverhalten hinweisen, auch wenn Sie genau wissen, wo das Problem liegt,
• melden Sie Fehler so schnell wie möglich,
• versuchen Sie immer, den Fehler zwei- oder dreimal zu wiederholen; wenn dies nicht gelingt, erwähnen Sie es in Ihrem Ticket,
• wenn Sie die Gelegenheit haben, den Fehler direkt zu zeigen, tun Sie es,
• lassen Sie niemals Fakten aus, die Ihnen offensichtlich erscheinen, in Ihrem Ticket weg,
• wenn Sie die Gelegenheit haben, überprüfen Sie, ob der Fehler nur in einer bestimmten Situation oder auf einer bestimmten Hardwarekonfiguration auftritt.