Warum wird nicht empfohlen, mehrere Fehler in derselben Ausgabe / demselben Ticket zu veröffentlichen?

Ich bin mir nicht sicher, ob dies der richtige Ort ist, um die folgende konzeptionelle Frage zu stellen (Stackoverflow ist definitiv nicht).

Ich habe diese Frage in einer Multiple-Choice-Prüfung (einfache Antwort) gesehen, ähnlich wie bei den ISTQB- Prüfungen:

Warum wird nicht empfohlen, mehrere Fehler in derselben Ausgabe / demselben Ticket zu melden?

ein. Um den Bericht kurz und übersichtlich zu halten.

b. Weil die Entwickler möglicherweise nur einen Fehler beheben.

c. Weil die Tester der Testgruppe nach der Anzahl der gefundenen Fehler bewertet werden.

d. Fehlerverwaltungssysteme unterstützen diese Funktion mehrerer Fehler nicht.

Meine einzige Meinung ist, dass dies adie richtige Antwort ist.

b- Kann es nicht sein, da das Fix-Feedback-gelöst-geschlossen diesen Fall vermeiden sollte. c- Offensichtlich falsch.

d - Redmine / Trac-Plugins unterstützen mehrere Felder.

Die Antwort laut Antwortbogen ist b.

Kann mir jemand erklären warum? Kommentare mit Meinungen zu Antworten sind willkommen.

Stellen Sie sich vor, Stack Overflow hätte eine Richtlinie: Anstatt nur eine Frage zu stellen, kommen Sie und stellen in derselben Frage alle Ihre Probleme, die Sie in den letzten zwei Wochen hatten. Was würde Upvote und Downvote bedeuten? Wie lauten die Titel der Fragen? Wie akzeptiere ich die beste Antwort? Wie markiere ich die Frage?

Das Bug-Tracking-System dient zum ... Verfolgen von Bugs. Einen Fehler zu verfolgen bedeutet:

1. Erstellen eines Datensatzes, der besagt, dass möglicherweise ein Fehler vorliegt, mit Informationen zur Reproduktion,

2. Bestätigen, dass der Fehler tatsächlich existiert und kein beabsichtigter Fehler ist,

3. Behauptend, dass der Fehler jetzt behoben ist,

4. Bestätigung, dass der Fehler behoben wurde.

In einem sehr simplen Modell werden 1 und 4 vom Kunden und 2 und 3 vom Entwickler ausgeführt.

Stellen Sie sich folgendes Protokoll vor:

• Tag 1 [Kunde] Wenn Sie im Fenster "Produktdetails" auf die Schaltfläche "Entfernen" klicken, bleibt die Anwendung hängen. Ein Neustart der Anwendung zeigt, dass das Produkt nicht entfernt wurde. Das erwartete Verhalten besteht darin, das Produkt zu entfernen.

• Tag 4 [Entwickler] <Problem reproduziert>

• Tag 5 [Entwickler] <Problem in Revision 5031 behoben>

• Tag 12 [Kunde] <Ticket geschlossen: Problem behoben>

Das Protokoll ist einfach und übersichtlich . Sie können problemlos nachverfolgen, was wann getan wurde , welche Revision welchen Fehler behoben hat usw. Wenn beispielsweise das Fehlerverfolgungssystem in die Versionskontrolle integriert ist, können Sie beim Anzeigen einer bestimmten Revision überprüfen, welche Fehler darin behoben wurden.

Es ist leicht, Informationen zu finden . Der Status ist leicht zu erkennen (wird er reproduziert? Wenn das Ticket geschlossen wurde, warum?). Es ist einfach, Tickets zu filtern (Ich möchte Tickets anzeigen, die nur die Benutzeroberfläche der Plugins betreffen, da ich nur Tickets möchte, die geöffnet sind, älter als eine Woche sind und die mir von unserem Interaktionsdesigner zugewiesen wurden und mittlere oder hohe Priorität haben).

Es ist einfach, ein Ticket neu zuzuweisen oder ursprünglich zu bestimmen, wer für den Fehler verantwortlich sein soll.

Stellen Sie sich nun folgendes Protokoll vor:

• Tag 1 [Kunde] Die App bleibt hängen, wenn ich im Fenster „Produktdetails“ auf die Schaltfläche „Entfernen“ klicke. Die Hintergrundfarbe des linken Fensters ist dunkelblau, während sie violett sein sollte. Ich habe auch festgestellt, dass der Text des Fensters „Produktdetails“ nicht gut ins Deutsche übersetzt ist. wird es erwartet Wann wäre die endgültige Übersetzung verfügbar? Übrigens, haben Sie das neue Symbol erhalten, das ich für die Aktion "Produkt veröffentlichen" gesendet habe? Ich sehe es nicht im Fenster "Daten synchronisieren".

• Tag 6 [Entwickler] Ich habe die Farbe in lila geändert.

• Tag 7 [Entwickler] Ja, es ist normal, dass die Übersetzung ins Deutsche unvollständig ist.

• Tag 8 [Kunde] Ok für Deutsch. Was ist mit Italienisch? Lucia hat dir vor zwei Tagen die XML-Datei geschickt.

• Tag 9 [Entwickler] Jetzt ist alles in Ordnung.

• Tag 10 [Kunde] OK für die Schaltfläche "Entfernen"? Seltsam, an meinem Computer hängt es immer noch.

• Tag 11 [Entwickler] Nein, ich wollte sagen, dass die italienische Übersetzung in Ordnung ist.

• Tag 12 [Kunde] Ich verstehe. Vielen Dank. Aber es gibt ein Problem mit der Farbe. Sie haben es in dunkelviolett geändert, aber es sollte hellviolett sein, wie das obere Bedienfeld im Hauptfenster.

• Tag 13 [Entwickler] Ich habe das Symbol aktualisiert.

• Tag 14 [Kunde] Das Symbol? Welches Symbol?

• Tag 15 [Entwickler] Das Symbol, um dessen Aktualisierung Sie mich gebeten haben.

• Tag 16 [Kunde] Ich habe Sie nie gebeten, ein Symbol zu aktualisieren.

• Tag 17 [Entwickler] Natürlich haben Sie gefragt. Siehe dieses Ticket. Sie haben geschrieben, dass das Symbol zum Veröffentlichen von Produkten aktualisiert werden soll. Ich habe es getan.

  ⁞

• Tag 100 [Kunde] Und was ist mit den Einträgen im Protokoll?

• Tag 101 [Entwickler] Ich habe keine Ahnung, wovon Sie sprechen. Es ist nicht einmal in diesem Ticket, aber in 6199. Ich schließe dieses als gelöst. <Ticket geschlossen: Problem behoben>

• Tag 102 [Kunde] Das Problem konnte nicht behoben werden. Ich spreche von den Einträgen im Protokoll: Ich habe dir letzte Woche gesagt, dass der Text manchmal ungültig ist, wenn er Unicode-Zeichen enthält. Erinnerst du dich? <Ticket wieder geöffnet>

• Tag 103 [Entwickler] Ich erinnere mich vage an so etwas, aber nachdem ich die letzten drei Seiten dieses Tickets durchsucht habe, kann ich keine Spur finden. Kannst du nochmal schreiben was das Problem war?

  ⁞

• Tag 460 [Entwickler] Ich habe zwei Stunden lang nach einer Spur gesucht, die Sie zu den Dateien geschrieben haben, die verschlüsselt über das Netzwerk gesendet wurden. Ich bin nicht sicher, ob ich die genaue Anfrage finden kann.

• Tag 460 [Kunde] Ihr solltet wirklich besser organisiert sein. Ich habe Sie in den letzten zwei Wochen viermal über dieses Problem informiert. Warum vergisst du alles?

  ⁞

Worum geht es in diesem Protokoll? Es wurde 43 Mal gelöst und 43 Mal wiedereröffnet. Bedeutet das, dass der Entwickler so dumm ist, dass er das gleiche Problem 460 Tage lang nicht lösen kann? Ah, nein, warte, dieses Ticket wurde mittlerweile 11 Entwicklern zugeteilt. Was ist das Problem? Wie suche ich nach einem bestimmten Thema? Eigentlich ist es Vanessa zugewiesen, aber ihre fünf Kollegen sind auch von sieben der elf Probleme in diesem Ticket betroffen. Wann sollte das Ticket geschlossen sein? Ist es, wenn die Hälfte der Probleme gelöst sind? Oder vielleicht zehn von elf?

Hinweis: Möglicherweise glauben Sie, dass solche Protokolle nicht vorhanden sind. Glauben Sie mir, ich habe mehr als einmal gesehen.

Nur um Ihre Aussage zu kommentieren:

kann es nicht sein, da das fix-feedback-resolved-closed diesen Fall vermeiden sollte

Dies setzt voraus, dass alle aufgetretenen Fehler gleichzeitig behoben werden. Stellen Sie sich ein Szenario vor, in dem ein Ticket für Version 1 des Produkts mit zwei Problemen erstellt wird:

1. Eine Schaltfläche zum Zurücksetzen des Formulars sendet das Formular tatsächlich, anstatt die Werte zu löschen
2. Die Schriftgröße auf der Schaltfläche beträgt 110%, wenn sie 115% betragen soll.

Beides ist für einen Tester richtig, da beide Fehler bei der Implementierung sind. Angenommen, der Product Owner entscheidet, dass die erste Teilaufgabe ein Blocker ist, der freigegeben werden soll (dh, sie muss behoben werden, bevor das Produkt in Betrieb genommen werden kann), die zweite Aufgabe ist jedoch ein geringfügiges Problem (dh sie kann in einer Version 1 behoben werden). 1 Veröffentlichung).

In diesem Fall haben wir keine andere Wahl, als Nummer 2 in ein eigenes Ticket aufzuteilen (oder das Risiko, es zu vergessen). Wenn wir das können, bedeutet dies, dass sie unabhängig voneinander implementiert, getestet und implementiert werden können. In diesem Fall ist es sinnvoll, von Anfang an einzelne Probleme zu haben.

Umfang:

Diese Antwort (und die Frage) scheint nur für die Verfolgung von Codefehlern anwendbar zu sein, bei denen der Quellcode nicht der Spezifikation oder den Absichten des Programmierers entspricht.

Im Gegenteil, es ist üblich, dass GUI-Fehlertickets mehrere Spezifikationen enthalten, da jedes GUI-Ticket quasi ein "Redesign" (Designfehler), eine "überarbeitete Spezifikation" oder eine "Feature-Anfrage" (fehlende Funktionalität) ist.

Ein wichtiger Zweck der Fehlerverfolgung ist die Kommunikation und Koordination zwischen mehreren Rollen (Programmierer, Tester, Kunden und Manager).

In Projekten, in denen die Codequalität eine hohe Bedeutung hat (beispielsweise im Vergleich zur Benutzerfreundlichkeit), kann die Fehlerverfolgung aus mehreren Facetten bestehen, von denen sich eine auf die Verfolgung von Codefehlern konzentrieren würde , getrennt von der Verfolgung von Verbesserungen und Kundenanfragen.

Der Zweck des Codefehlerverfolgungssystems ist:

• Die unabhängige und eindeutige Verfolgung von unabhängig reproduzierbaren Fehlern zu ermöglichen, und
• Die bestmögliche Annäherung (Eins-zu-Eins-Entsprechung) an die Grundursache jedes Fehlers.

Dabei sollten die folgenden wünschenswerten Eigenschaften maximiert werden:

• Skalieren Sie effizient, wenn die Anzahl der Fehler mit der Zeit zunimmt.
• Verhindern Sie das Moving-Target-Syndrom.

Haftungsausschluss: Diese Formulierung ist aus meiner persönlichen Erfahrung. Es kann für den Zweck der Zertifizierungsprüfung unzureichend oder falsch sein.

Unabhängiges und eindeutiges Tracking bedeutet:

1. Jeder gültige Fehler kann ohne Mehrdeutigkeit entweder behoben oder nicht behoben werden.

   • Grund 1: Vereinfachung der Verwaltung,
     • Beispiel: Es ermöglicht die Verwendung der "Anzahl der nicht aufgelösten Tickets" als Metrik.
   • Grund 2: um in umsetzbaren Gegenstand zu übersetzen
     • Beispiel: Wenn es nicht gelöst ist, liegt die Verantwortung beim zugewiesenen Programmierer. Wenn es gelöst, aber nicht geschlossen wird, liegt die Verantwortung beim zugewiesenen Tester (Prüfer).
   • Konsequenz: Bei dieser Methodik verdient es ein teilweise behobener Fehler, in mehrere abhängige Fehler unterteilt zu werden.

2. Unabhängig reproduzierbare Fehler sollten unabhängig verfolgt werden.

   • "Unabhängig reproduzierbar" bedeutet, dass sie unterschiedliche Zustände haben können. Eines kann fixiert erscheinen, während das andere kaputt bleibt.
   • Grund: Minimierung der Diskrepanz zwischen Fehlerverfolgung und Ursachenanalyse.
     • Es wird angenommen, dass jede Grundursache, die auf einen Codefehler zurückzuführen ist, mindestens eine Codeänderung erfordert.
     • Sind zwei Fehler unabhängig voneinander reproduzierbar, sind mehrere Codeänderungen erforderlich.
     • Sind zwei Fehler unabhängig voneinander reproduzierbar, müssen beide getestet (verifiziert) werden, da das Bestehen eines Tests nicht bedeutet, dass der andere Test bestanden wird.
   • Beispiel 2: Wenn anfangs angenommen wurde, dass zwei Symptome dieselbe Ursache haben und daher in dasselbe Ticket klassifiziert wurden und später gezeigt wurde, dass sie unabhängig reproduzierbar sind, sollten sie in zwei Tickets aufgeteilt werden.

Betrachten Sie es aus der Perspektive einer anderen Person, die das System verwendet und einige Monate später auftaucht. Sie finden einen Fehler im Programm. Sie googeln herum und sehen, dass es ein Support-Ticket gibt, das ihrem Problem entspricht. Und hey, es ist geschlossen! Genial! Es wurde in der neuesten Version behoben! Also, sie aktualisieren ... und der Bug ist immer noch da? Was ist los mit diesen dummen Entwicklern?!?

Eigentlich gar nichts. Es hat sich herausgestellt, dass mit der Person, die den Fehlerbericht einreicht, etwas nicht stimmt. Sie haben zwei Bugs im selben Ticket eingereicht. Eines war einfach zu reparieren und wurde schnell repariert, das andere nicht. Auch wenn Sie so etwas wie fix-feedback-resolved-closed verwenden, es möglicherweise nicht klar, was gerade für einen externen Beobachter vor sich geht.

Es ist viel besser, jedem Fehler ein eigenes Ticket zuzuweisen. Wenn Sie mehrere Fehler haben, die miteinander zusammenhängen, sich aber offensichtlich voneinander unterscheiden, verfügen die meisten Fehlerverfolgungssysteme über eine Funktion, mit der Sie einen Fehler mit einem anderen verknüpfen können. (Und wenn nicht, können Sie es einfach in den Bericht einfügen. "Siehe auch Fehler # 12345.")