So schließen Sie einen nicht mehr relevanten Fehler

21

Ich bin derzeit in einem mittelgroßen Team von Webentwicklern. Wir verwenden Jira für die Fehlersuche .

Wir arbeiten an einem Produkt mit häufigen Layoutänderungen. In einigen Browsern werden häufig Fehler im Layout gemeldet. Manchmal hat sich das Layout bereits geändert, wenn wir uns mit einem Fehler mit niedriger Priorität befassen und er ist nicht mehr relevant.

Wie sollen wir es schließen?
Was ich meine, ist, wie wir diese Probleme behandeln sollen ? Während Jira die von uns verwendete Fehlerverfolgungssoftware ist, interessiert mich mehr, wie man mit solchen Problemen im Allgemeinen umgeht.
Ist es überhaupt wichtig? (Wir werden vielleicht später zum Layout zurückkehren, aber das ist sehr unwahrscheinlich.)

issue-tracking jira

— Benjamin Gruenbaum
quelle

8

Too Localized;)

— Yannis

4

Ist dies nicht der Fall, ist es möglicherweise besser für SO geeignet, da es möglicherweise werkzeugspezifisch ist

— jk.

6

@jk. Heh, ich meinte "zu lokalisiert" als Vorschlag / Antwort auf die Frage, nicht dass die Frage selbst "zu lokalisiert" ist. Wenn ich letzteres gedacht hätte, hätte ich es einfach geschlossen.

— Yannis

2

@YannisRizos doh! vielleicht hätte es dann eine antwort sein sollen;)

— jk.

6

@jk. Ich denke, die zweite Frage ist interessanter (spielt es überhaupt eine Rolle?), Aber ich habe gerade keine Zeit, sie zu beantworten (und ich bin mir nicht sicher, ob die Antwort, die sich in meinem Kopf bildet, eine gute ist). Was die erste Frage betrifft, wenn dieser Thread zu einem "Wort- / Phrasenvorschlag" wird, wird er möglicherweise als "nicht konstruktiv" geschlossen. Also, Antwortende, ignorieren Sie bitte nicht die zweite Frage, das ist das aktuelle und interessante.

— Yannis

26

Nuancen wie diese sind wichtig, wenn Sie Issue Tracker als Mittel betrachten, um den Status von Problemen zu kommunizieren, die im Projekt gemeldet wurden. Zu diesem Zweck ist es sinnvoll, einige Anstrengungen zu unternehmen, um sicherzustellen, dass der Fehlerbericht leicht zu lesen und zu verstehen ist.

Diese Situation wird weniger verwirrend, wenn Sie sie aus der Perspektive eines Testers betrachten. Wenn Ihr Team keinen Tester hat, stellen Sie sich einen vor (oder stellen Sie noch besser einen ^{1 , 2 , 3 ein} ).

Okay, es gab also einmal einen Fehler, der vom Tester mit älteren Versionen Ihrer Anwendung reproduziert werden konnte (Randnotiz in dem unwahrscheinlichen Fall, dass Sie keine Kopien älterer Versionen behalten, dann haben Sie viel viel größere Probleme Team als veraltete Bugs). Tester kann es sehen und erkennen, was falsch ist, was es zu einem Bug macht.

Jetzt sagen Sie: "Das Layout hat sich bereits geändert und es ist nicht mehr relevant." - Die hochgesteckte Aussage, die nicht mehr relevant ist, macht den Tester zu einer viel einfacheren Aussage: Das Problem ist verschwunden .

Es ist wichtig zu beachten, dass professionelle Tester das System als Black Box betrachten sollten . Aus dieser Perspektive spielt es keine Rolle, wie genau das Problem aufgetreten ist, es könnte sich um eine Layoutänderung oder schwarze Magie oder eine vollständige Neugestaltung oder eine konkrete Codeänderung handeln.

Aus Sicht der Black Box ist Ihre Situation ziemlich einfach. Es gab ein Problem, das in älteren Releases immer noch reproduzierbar ist. Jetzt behaupten Sie, dass neuere Releases kein solches Problem mehr haben. Für einen Tester führt dies zu einer Behauptung, dass der Fehler behoben ist , bzw. zu der Notwendigkeit, zu überprüfen, ob die Behauptung wahr ist.

Professioneller Tester würde Ihre ältere Version nehmen, prüfen, wie das Problem dort vorliegt, dann eine neuere Version nehmen und prüfen, ob sie nicht mehr vorhanden ist oder noch vorhanden ist.

Die genaueste Möglichkeit, Fehler zu behandeln, wie Sie sie beschreiben, besteht darin, sie als behoben zu schließen . Natürlich würde es nicht schaden, wenn Sie in den Kommentaren klarstellen, dass der Fix als unbeabsichtigter Nebeneffekt einer Layoutänderung aufgetreten ist.

Einer der benutzerdefinierten JIRAs, mit denen ich in einem früheren Projekt gearbeitet habe, hatte die Auflösung "Fixed By Design", um ziemlich tiefgreifende Änderungen mit vielen Konsequenzen zu kommunizieren, einige absichtlich, andere nicht. Für den von Ihnen beschriebenen Fall könnte dies auch als Ersatz für "Behoben" angesehen werden, da dies den Ticketleser darauf hinweist, dass es sich eher um einen Nebeneffekt als um eine absichtliche Codeänderung handelt.

— Mücke
quelle

2

Fixed by Design würde für mich das genaue Gegenteil davon bedeuten. In meinen Augen bedeutet Design "absichtlich" (es ist das Gegenteil von "aus Versehen").

— TRiG

Ich bin damit einverstanden, dass "fest" ausreicht. Es spielt überhaupt keine Rolle, ob es beabsichtigt war oder eine Nebenwirkung anderer Veränderungen war. Ich stimme jedoch auch @TRiG zu, dass "Fixed by Design" verwirrend ist.

1

@TRiG na deswegen habe ich darauf hingewiesen, dass man in Kommentaren die genauen Details besser erklärt. Fixed By Design ist ein bisschen breit; In dem Projekt, das ich gesehen habe, wurde es verwendet, um tiefgreifende Veränderungen mit vielen Konsequenzen zu kommunizieren, von denen einige absichtlich waren, andere nicht - und um Fälle wie diesen abzudecken. Beachten Sie auch, weder Fragetext noch meine Antwort bedeuten „fix aus Versehen“ (was für Fehler?) - hier „unbeabsichtigte“ ist viel viel besser passen

— gnat

1

Alle Antworten sind gut, aber dieser scheint es zu nageln. Vielen Dank an alle.

— Benjamin Gruenbaum

6

Wie wäre es mit "Fixed by Redesign"?

— Pinguin

47

Wir lösen Probleme wie "Veraltet". Dies ist keine Standardauflösungsoption in JIRA, aber das Hinzufügen ist einfach genug.

— Kris
quelle

+1, wenn Sie es nicht hinzufügen können, wählen Sie es als nicht ein Fehler und kommentieren, warum

— tgkprog

9

JIRA (und ich bin sicher, dass andere Bug-Tracker) ermöglicht es Ihnen , benutzerdefinierte Auflösungen festzulegen, sodass Sie eine Auflösung für "Überholt von Ereignissen" oder "Irrelavant" oder Ähnliches einrichten können, um die Schließung so auszudrücken, wie Sie möchten

Ist das wichtig? Das hängt davon ab, für uns würde ich ja sagen, da unser Kunde übermäßig besorgt ist über die Anzahl der offenen Probleme in unserem Tracker. Daher ist es für uns nützlich zu sagen, dass diese geschlossen sind, weil sie nicht mehr relevant sind, ohne das Problem vollständig zu löschen .

Auch ohne einen Kunden, der von Problemnummern betroffen ist, ist es auf jeden Fall nützlich, alte offene Probleme, die nicht mehr relevant sind, zu entfernen, um die Unordnung im Browser zu verringern.

— jk.
quelle

1

"Over Taken By Events" ist zu lang (imho), ich würde ein einziges Wort verwenden (irrelevant / veraltet), nur weil es einfacher zu suchen ist und weniger Platz beansprucht (in Berichten usw.). Das einzige Mal, dass wir die Menge unserer veralteten Bugs kannten, war, als sie in großen Mengen auftraten, und das deutete auf ein Kommunikationsproblem hin. Unsere Tester waren mit dem, woran unsere Entwickler arbeiteten, nicht auf dem neuesten Stand. Sie hatten das Memo verpasst, dass die Dinge etwa eine Woche lang schuppig sein werden und machten (unnützen) Lärm. Rückblick auf unsere Beobachtungen. Fehler haben uns geholfen, ein Loch in unseren Kommunikationsprozessen zu finden und zu reparieren.

— Yannis

3

Wir verwenden eigentlich das Akronym OBE, aber ich denke, das tatsächlich verwendete Wort ist der am wenigsten interessante Punkt. Es geht darum, etwas auszuwählen, das für Sie funktioniert

— jk.

3

@YannisRizos: Beheben von Meta-Bugs mit Bugs. Wie cool ist das!

— Jörg W Mittag

@YannisRizos-Suche ist kein großes Problem, da die gültigen Auflösungen ohnehin aus einem Dropdown-Menü (in JIRA) ausgewählt werden

— jk.

2

@Yannis. Ich würde darüber den Schlaf verlieren: Überholt sollte ein Wort sein.

— TRiG

5

Wir verwenden FogBugz, aber ich bin sicher, dass hier das Gleiche (oder Ähnliches) zutrifft:

Wir benutzen einfach "Resolved (Fixed)" und kommentieren in der Auflösung etwas wie "Fixed by case 12345".

FogBugz stimmt mit "case \ d +" überein und verknüpft die beiden unter "Related Cases". Wenn Jira dies nicht tut, sollte es einfach sein, einen Link hinzuzufügen.

Dies ist IMO besser als eine "Too Localized" -Variante, da es sich um einen tatsächlichen Fehler handelte, und besser als "Obsolete", da dieses Feature behoben wurde und nicht einfach entfernt wurde.

— Izkata
quelle

3

Behebung durch Ernüchtern und erneutes Überprüfen der <- wahren Begebenheit.

— Yannis

1

Jira erlaubt diesen Ansatz ebenfalls. Erwähnen Sie einfach die Problemnummer in den Lösungskommentaren und Jira verwandelt sie in einen Hyperlink.

— Marjan Venema