Überlegungen zur Fehlerberichterstattung in Teams

Hier ist eine frustrierende Situation: Jemand bemerkt einen echten Layout-Fehler oder eine Art Glitch, aber es gelingt ihm nicht, das Problem genau zu beschreiben, wenn er davon erzählt. Als Frontend-Entwickler und gute Teamplayer ist es unsere Verantwortung, einen Workflow für die Meldung, Katalogisierung und Beschreibung von Fehlern zu etablieren, auf die Menschen wahrscheinlich stoßen werden.

Ein System für Fehlerberichte in einem Teamumfeld hat eine Menge Vorteile

• Zu wissen, welche Fehler aktuell existieren.
• Zu verstehen, wer an was arbeitet (und was er braucht).
• Einen Überblick darüber zu bekommen, wie viel Zeit für die Fertigstellung der Dinge benötigt wird.
• Aufgaben zu finden, die blockiert sind oder die eine Art Abhängigkeit erfordern, bevor sie angegangen werden.

Der erste Schritt ist die Wahl eines Tools, mit dem sich jeder wohlfühlt

Mit einem soliden System zur Fehlerbehebung sind wir in einer viel besseren Position, um großartige Arbeit zu leisten. Dennoch ist es wichtig zu beachten, dass gute Fähigkeiten zur Fehlerberichterstattung nicht nur eine Voraussetzung für Entwickler sind. Jeder im Team sollte in der Lage sein, einen Fehler zu finden und möglichst viele Informationen dazu bereitzustellen. Das bedeutet, dass Designer, Entwickler und Projektmanager aller Erfahrungsstufen keine Angst haben sollten, das Fehler-Tool zu nutzen und sich einen Überblick über das Projekt als Ganzes zu verschaffen.

Ich habe immer festgestellt, dass Trello mein persönlicher Favorit ist, da es für den Rest des Teams viel mehr Sinn ergibt, aber das bedeutet nicht unbedingt, dass es für Ihren speziellen Anwendungsfall am besten geeignet ist. Hier sind einige der beliebtesten Fehlerverfolgungstools und -dienste, die es wert sind, ausprobiert zu werden

• Trello
• Stack
• Sifter
• Waffle
• Basecamp
• JIRA
• GitHub Issues
• Asana
• BugHerd

Unabhängig vom gewählten Tool müssen wir am Ende sicherstellen, dass alle mit dem vorgeschlagenen Workflow zufrieden sind, da wir die Hilfe aller benötigen werden, um das Projekt zu dokumentieren, aufzuzeichnen und nach potenziellen Fehlern zu durchsuchen.

Ein nutzloser Fehlerbericht

Selbst wenn Sie das perfekte Tool wählen, bedeutet das nicht unbedingt, dass es von jedem auf hilfreiche Weise genutzt wird. Es gab viele Fälle, in denen ich Schwierigkeiten hatte, einen gemeldeten Fehler aufgrund mangelnder Informationen zu finden.

Nicht sehr hilfreich

• „Der Listenstil ist in IE kaputt“
• „Beim Scrollen über die Seite gibt es komische Glitches“

Tatsächlich sind diese Arten von Kommentaren für einen Entwickler fast nutzlos, da sie nicht *spezifisch* genug sind. Entwickler würden es vielmehr bevorzugen, wenn ein Fehlerbericht Informationen wie *wer, was, wo, wann und warum* enthält.

Ein hilfreicher Fehlerbericht

Obwohl dies vollständig vom jeweiligen Fall abhängt, wäre es am besten, etwas Ähnliches zu lesen wie

„Der spezielle Listenstil auf der Kontaktseite ist in Firefox und IE11 falsch links neben seinem Container positioniert. Bitte sehen Sie sich das angehängte Bild für weitere Informationen an.“

Von hier aus kann ein Entwickler den fraglichen Fehler sofort finden und mit der Ausarbeitung einer richtigen Lösung für das Problem beginnen.

Aber wie helfen wir allen anderen im Team, *großartige* Fehlerberichte zu schreiben?

Ich habe es als äußerst hilfreich empfunden, zu Beginn des Projekts mit jedem im Team zusammenzusitzen und detailliert zu erläutern, wie wir mit ihnen arbeiten sollen. Wer sagt, wann ein Fehler behoben ist? Wer überprüft welchen spezifischen Code-Schnipsel? Welche automatisierten Tools sollen wir zur Fehlersuche verwenden? Welche Ressourcen benötigen wir vom Designteam, wenn sie einen finden? Dies sind wichtige Fragen, die zu frustrierenden Problemen führen können, wenn sie unbeantwortet bleiben.

Ich habe eine kurze Liste von Dingen zusammengestellt, die ich von den meisten Fehlerberichten erwarte

1. Seien Sie kurz und bündig (aber seien Sie kein Idiot)

Idealerweise wünschen wir uns Aufzählungspunkte statt langer Sätze, damit ein Entwickler das Problem so schnell wie möglich finden kann, obwohl uns das keine Entschuldigung gibt, kurz angebunden zu sein. Es ist am besten, das Problem so genau und mit so wenig Hindernissen wie möglich zu beschreiben. Wenn es jemanden gibt, der diese spezielle Funktion entwickelt hat und deren Einzelheiten kennt, sollten Sie sie vielleicht zuerst ihm zuweisen. Aber geben Sie ihm nicht die gesamte Schuld.

2. Stellen Sie sicher, dass Sie Screenshots und/oder GIFs hinzufügen

Besonders bei Animations- und komplexen Interaktionsfehlern sind animierte GIFs fast unerlässlich, um die Eigenheiten des Fehlers hervorzuheben. Für die meisten Fälle hilft jedoch ein einfacher Screenshot, um die Ansicht oder Vorlage zu finden, in der der Fehler auftritt.

Tools zum Erfassen animierter GIFs

• GifGrabber
• PicGIF
• LICEcap

(Screenshot / GIF / Video) + Cloud-Speicher-Tools

• Droplr
• CloudApp
• Screenr

Und vergessen Sie nicht, dass Sie in GitHub Issues einfach Screenshots per Drag & Drop ziehen können

3. Identifizieren Sie die Browserversion

Es ist nicht sehr hilfreich, wenn Sie einfach nur den Namen des Browsers wie „Chrome“ oder „IE“ angeben. Es ist viel besser, wenn Sie eine bestimmte Browserversion wie „Chrome 42“ oder „IE8“ angeben. Wenn Sie jedoch auch herausfinden können, ob der Fehler in anderen Browsern nicht vorhanden ist, ist das noch besser, z. B. „Ich habe diesen Fehler in iOS 8.3 gefunden, kann ihn aber in keinem anderen Webkit-Browser reproduzieren.“ Mit dieser Art von Information können Sie einem Entwickler viel Zeit sparen und er kann schneller erkennen, was schief geht.

Wenn Sie sicherstellen möchten, dass Sie alle möglichen Informationen weitergeben, können Sie ein Tool wie Support Details verwenden, das viele Dinge erfasst und es Ihnen ermöglicht, sie per E-Mail oder PDF zu versenden (oder einfach einen Screenshot davon zu machen). Wenn Sie eine eigene Fehlerberichterstattung kontrollieren, können Sie sogar versteckte Felder mit diesen Informationen erfassen und vorab ausfüllen, sodass Sie diese ohne Aufwand vom Melder erhalten.

4. Vermerken Sie, auf welcher Vorlage, Ansicht oder Seite der Fehler gefunden werden kann

Wenn er auf der Seite /blog oder /contact-us liegt oder in einem bestimmten Teil wie dem Header oder Footer zu finden ist, informieren Sie den Entwickler so schnell wie möglich darüber.

Eine vollständige URL ist normalerweise sehr hilfreich.

5. Vergessen Sie nicht, das spezielle Modul oder die Klasse zu erwähnen, die das Problem verursachen könnte

Wenn Sie sich im Frontend besser auskennen und einem Entwickler eine Lösung für ein Problem anbieten möchten, müssen Sie zwei Dinge tun: Erstens müssen Sie von jedem Entwickler im Team eine „High Five“ erhalten, denn das Melden von Fehlern und gleichzeitige Mitteilen, wie man sie behebt, ist eine große Sache. Zweitens müssen Sie wahrscheinlich einen reduzierten Testfall erstellen. Dies beinhaltet das Aufteilen des Codes in kleine Teile und das schrittweise Entfernen, bis enthüllt ist, was genau passiert. Mit diesen Informationen werden Sie den Bereich des fehlerhaften Codes eingrenzen und das Leben aller ein wenig einfacher machen.

6. Prüfen Sie, ob es Konsolenfehler oder Benachrichtigungen gibt

Anstatt die Konsolenfehler zu kopieren/einzufügen, ist es wahrscheinlich am besten, einen Screenshot zu machen, wenn es Warnungen gibt. Diese sind möglicherweise nicht mit dem spezifischen Fehler, den Sie gefunden haben, verwandt, könnten aber genau das sein, was alles durcheinander bringt.

7. Überprüfen Sie doppelt, ob der Fehler bereits von jemand anderem gefunden wurde

Doppelte Fehlerberichte waren in den Projekten, an denen ich gearbeitet habe, generell kein großes Problem. Wenn es jedoch viele Probleme gibt, lohnt es sich auf jeden Fall, einen kurzen Blick auf die archivierten Fehler oder die aktuell offenen Probleme zu werfen, um zu sehen, ob Ihr Fehler dort zu finden ist.

Diese Aufgabe kann auch beinhalten, dass Sie durchsehen, welche Fehler ähnlich sind, und das Problem in der App, die Sie verwenden, kennzeichnen. Wenn der Fehler gefunden *wurde*, ist es vielleicht sinnvoll, weitere Informationen hinzuzufügen oder auf der Karte zu vermerken, wo Sie eine neue Instanz desselben Problems gefunden haben.

8. Gruppieren Sie Aufgaben in spezifische Kategorien

Ich habe es als besonders nützlich empfunden, ein Problem mit der Labels-Funktion in Trello als „blockiert“ zu markieren. Ein großes rotes Tag zeigt jedem, dass es ein weiteres Problem im Zusammenhang mit dieser Aufgabe gibt, das zuerst behoben werden muss.

Ähnlich ist es hilfreich, die Aufgaben aller in spezifische Bereiche zu unterteilen, wie z. B.

• Inhalt
• Design
• Frontend
• Integration / Backend
• Fehler
• Code-Review
• Fertig

Dies gibt uns einen Überblick über den Projektzeitplan und gibt Entwicklern die Möglichkeit, alle Fehler auf einen Blick zu sehen.

Die meisten Fehlerberichtssoftware bietet die Möglichkeit, Dinge zu klassifizieren. Tagging, Kategorisierung, Kennzeichnung, Zuweisung, was auch immer.

9. Dokumentieren Sie Ihren bestehenden Workflow für Fehleraufgaben

Wenn Sie der Meinung sind, dass Sie einen großartigen Workflow etabliert haben, sollten Sie vielleicht ein Dokument erstellen, das Ihren Prozess detailliert beschreibt. Dies ist möglicherweise nicht nur für Ihre eigene Organisation gedacht und kann anderen helfen, damit sie nicht die gleichen Fehler machen. Zwei Referenzen kommen mir in den Sinn: das Thoughtbot Playbook und Harry Roberts' Beitrag zu seinem Trello-Workflow

Zusammenfassung

Ich war schon immer der Meinung, dass eine Liste von Fehlern kein einschüchternder, überwältigender Druck sein sollte, der jeden im Team mit dem Wunsch belastet, zu kämpfen und zu streiten. Stattdessen sollte eine Fehlerliste uns inspirieren, die Ärmel hochzukrempeln und uns zu ermutigen, zu helfen, wie wir können. Wenn wir also ein wenig Zeit damit verbringen, diese winzigen Details unseres Prozesses zu klären, können wir vielleicht all diese Lasten abwerfen und weiterhin großartige Dinge für das Web bauen.

Wie sieht Ihr Fehlerüberprüfungsprozess aus? Welche Tools finden Sie nützlich? Hinterlassen Sie unten einen Kommentar und ich werde diesen Beitrag für zukünftige Referenz aktualisieren.