Was sind Best Practices für die Fehlerverfolgung?

Jedes Projekt wird seine eigenen Ziele für ein Fehlerverfolgungssystem haben. Nur Sie können Ihre definieren, aber asoundmove macht einige gute Punkte . Um sich nicht zu wiederholen, gehe ich einfach davon aus, dass Sie diese Antwort lesen und direkt einsteigen:

1. Stellen Sie sicher, dass Ihr Prozess Ihre Ziele unterstützt. Sie wären überrascht, wie oft Menschen ein Tool auswählen oder einen Prozess implementieren, weil es „das Beste “ ist, aber letztendlich niemand es schätzt. Es bietet niemandem etwas Nützliches und stirbt.
2. Fangen Sie klein an. Ein effektives Prozessänderungsmanagement braucht Zeit, und Sie werden mehr Erfolg haben, wenn Sie im Laufe der Zeit kleine Änderungen implementieren, als zu versuchen, den „perfekten“, aber nachverfolgten Prozess zu entwerfen und ihn auf einmal auf Ihr Team zu werfen.
3. Bedenken Sie, dass Ihre Bug-Tracking-Datenbank neben der täglichen Behebung von Fehlern noch weitere Verwendungszwecke haben könnte. Es kann selbst als Planungstool verwendet werden, um zu überwachen, wann Sie das Team zu sehr belasten (mehr Fehler), oder um die zukünftige Arbeit abzuschätzen.
4. Wenn Sie es verwenden, um Aufgaben zu verfolgen, seien Sie vorsichtig. Häufige Fehler, die Sie beim Verfolgen von „Aufgaben“ in einem Fehlerverfolgungssystem machen können:
   • Zu feine Details. Angenommen, es dauert mindestens 10 oder 15 Minuten , um eine anständige Aufgabenbeschreibung zu schreiben, müssen Sie sich fragen, wie lange diese Aufgabe dauern wird? Wenn es etwas ist, das in etwa einer Stunde erledigt werden könnte, fügen Sie jeder Aktivität, die Sie unternehmen, einen enormen Verwaltungsaufwand hinzu.
   • Vage Ausstiegskriterien. Fehler und Verbesserungen sind in einem Fehlerverfolgungssystem „einfach“ zu verwalten – es ist leicht zu erkennen, wann Sie fertig sind. Abhängig von Ihrem Prozess validiert / bestätigt / testet jemand, dass die angeforderte Änderung zufriedenstellend durchgeführt wurde. Es ist einfach, „Aufgaben“ zu schreiben, die keinen klaren Mechanismus haben, um festzustellen, ob die Aufgabe richtig, ausreichend oder vollständig erledigt wurde. Diese Aufgaben werden zu einem Verwaltungsaufwand.
   • Verdoppelung des Aufwands. Erfassen Sie Aufgaben in einem Busverfolgungssystem, melden sie aber auch in Statusberichten oder als Aufgaben in Gantt / Zeitplänen?
5. Alle Änderungsanforderungen, ob Fehler, Erweiterungen oder Aufgaben, die mit einer Art von Kundenanforderung verbunden sind (die möglicherweise auch in derselben Datenbank erfasst werden), und geschlossene Änderungsanforderungen haben entweder eine Lösung, die erklärt, warum keine Änderung vorgenommen wird, oder einen Link zu der Änderung Artefakte. Vorzugsweise werden diese geänderten Artefakte in Ihr Revisionskontrollsystem eingecheckt: Quellcode, Build- und Initialisierungsdateien, Tests und Dokumente.

Brian, ich war in deiner Haut. Meine Hauptempfehlung lautet: „Vergiss Redmine, konzentriere dich vorerst auf deinen Prozess.“

Nachdem Sie einen guten Prozess für die Fehlerverfolgung definiert haben, gehen Sie zurück, um zu sehen, ob Redmine passt.

Weitere Empfehlungen aufgrund von Erfahrung:

• Denken Sie daran, dass die häufigsten Vorfälle entweder (Bugs (manche nennen sie Defekte) und Verbesserungen (manche nennen sie Features))
• Erstellen Sie einen Prozess für Fehler und einen anderen Prozess für Merkmale (Jeder Prozess erfordert eine andere Behandlung)
• Holen Sie sich Engagement von Ihrem Team
• Holen Sie sich Engagement von Ihren Kunden (nur intern)
• Haben Sie einen Prozess zur Behandlung von Ausnahmen, das ist nützlicher als Sie denken

Fragen Sie sich, was Sie von Ihrem Fehlerverfolgungssystem erwarten und welche Verbindungen es zu anderen Systemen haben muss (Rückverfolgbarkeit, Durchsuchbarkeit)?

Sind die folgenden Punkte für Sie relevant (keine abschließende Aufzählung)?

• Verfolgen Sie Fehler während der gesamten Lebensdauer des Projekts (entwickeln und vergessen)
• Verfolgen Sie Fehler während der gesamten Lebensdauer des Produkts (langfristiger Support)
• Verfolgen Sie Fehler nur, um sie zu korrigieren?
• Verfolgen Sie Fehler, um auch herauszufinden, wie Sie Ihre Prozesse verbessern können (kostet mehr, sollte aber längerfristige Vorteile bringen)?
• Müssen Sie die für die Untersuchung und Lösung aufgewendete Zeit nachverfolgen (um die Kosten zu analysieren, gibt es sicher andere Möglichkeiten, dies zu tun)?
• Es empfiehlt sich, in den Kommentaren zur Versionskontrolle für die Lösung auf die Fehlernummer zu verweisen.
• Es empfiehlt sich, Fehlerberichte mit relevanten Testfällen und/oder relevanten Abschnitten des Designdokuments zu verknüpfen, auf die sie sich beziehen (und auf damit verbundene Geschäftsanforderungen). Auf diese Weise können Sie den Verlauf von Fehlern überprüfen, wenn Sie diese ändern Anforderungen oder Designelemente (eine solche Rückverfolgbarkeit ermöglicht eine bessere Risikoanalyse und Testanforderungsplanung für zukünftige Änderungen).
• Schreiben Sie einen Nicht-Regressions-Testfall als Teil der Lösung dieses Fehlers.

Als jemand, der Software getestet und erstellt hat (und ein Team leitet), sind hier einige der Punkte, die mir am meisten bedeuten, wenn es um Best Practices für Fehler geht

• Prozess, in erster Linie ... - Finden Sie jetzt die Fehlermanagement-/Testmethodik heraus. Dies wird Ihnen und allen Beteiligten später viele Kopfschmerzen ersparen (z. B. lassen Sie Ihre Entwickler Fehler nicht schließen, oder? Wer wird für die Überprüfung behobener Fehler verantwortlich sein?) Sehen Sie sich mehrere Testmethoden an und passen Sie sie an eine für Ihre Bedürfnisse. Definieren Sie die Rollen und Verantwortlichkeiten aller am Softwarequalitätsprozess Beteiligten. Finden Sie auch den Lebenszyklus Ihrer Fehler heraus. Die meisten der wichtigsten Tools (Bugzilla, Jira usw.) haben bereits einen Fehlerlebenszyklus eingebaut. Einige der besseren lassen Sie den Lebenszyklus so definieren, dass er Ihren Anforderungen entspricht.
• ... jetzt noch einmal kritisch - Jeder bekommt den Prozess, den er verdient, aber nicht immer den, den er wollte. Überprüfen Sie alles, was Sie im vorherigen Schritt gefunden haben, und stellen Sie sicher, dass Sie etwas haben, das funktioniert und alle Ihre Testanforderungen erfüllt. Beheben Sie alle Probleme, stellen Sie sicher, dass es jetzt funktioniert, und behalten Sie alles im Auge, falls etwas angepasst werden muss.
• Beschreiben Sie den gefundenen Mangel eindeutig! - Dies ist vielleicht nicht auf der Prozessebene, aber es ist eines meiner Lieblingsprobleme. Stellen Sie sicher, dass Mängel klar beschrieben werden, damit Sie verstehen können, was sie jetzt und in Zukunft sind, wenn jemand sie überprüfen muss. Es ist wirklich beunruhigend, auf einen 6-12+ Monate alten Fehler zurückzukommen und nicht in der Lage zu sein, herauszufinden, was das Problem war.
• Verfolgen Sie Ihre Fehler – Dies sagt Ihnen viel über den Zustand Ihrer Software aus. Durch das Verknüpfen von Fehlern mit bestimmten Testfällen und insbesondere mit Funktionsbereichen können Sie bestimmen, worauf Sie sich konzentrieren sollten. Wenn 70 % Ihrer Fehler auf die XYZ -Funktionalität zurückzuführen sind, bedeutet dies, dass die Qualität des Codes in diesem Bereich der Anwendung erneut überprüft werden muss?

Zusamenfassend:

• Befolgen Sie einen gut definierten Prozess, z. B.: bestätigen/reproduzieren -> Auswirkung analysieren und Priorität festlegen -> Fixes analysieren -> Fix
• Ehrlichkeit beim Tracking (wichtig für PM) - kein vorzeitiges Schließen von Bugs, kein Ablehnen von "unwichtigen Bugs"
• behalte auch die "kleinen" Bugs (wichtig, denn wenn du fertig bist, um es endlich fertig zu bekommen, werden auch diese Zeit stehlen)
• Sehen Sie sich täglich die Statistik „Kritisch, nicht behoben/gestartet“ an (z. B. im JIRA-Dashboard).
• Feature-Freeze früh genug

+1 zu Geo bezüglich der Konzentration auf Prozesse.

Vielleicht möchten Sie nach Testmethoden, Qualitätssicherung in der Softwareentwicklung und Variationen davon suchen.

Viele tolle Empfehlungen in diesem Thread. Die bloße Tatsache, dass Sie zur Fehlerverfolgung migrieren (im Gegensatz zur Verwendung von E-Mail und Whiteboards), wird in Ihrem Qualitätsmanagementprozess einen großen Schritt nach vorne bedeuten.

Das Einzige, was bisher in den Antworten zu fehlen scheint, sind Informationen zur Softwareversion. Wenn Sie eine Multi-Stream-Entwicklung durchführen oder n Versionen zurück von der aktuellen Version unterstützen, ist es für Sie sehr hilfreich, die Felder „Gefunden in“ und „Korrigiert in“ zu haben, damit Sie solche Dinge verfolgen können.