it-swarm.com.de

Sollten Entwickler Fehler in das Fehlerverfolgungssystem eingeben?

Während der Entwicklung (entweder Funktionen oder Fehlerkorrekturen) entdecke ich manchmal Fehler, die nicht direkt mit dem zusammenhängen, woran ich arbeite. Was soll ich in dieser Situation tun? Einfach reparieren? Versuchen Sie sich daran zu erinnern, es später zu beheben? Irgendwo aufschreiben? Oder geben Sie es in das Bug-Tracking-System ein?

Ich gebe es im Allgemeinen in das Bug-Tracking-System ein und lasse den Prozess von selbst ablaufen (d. H. Testen, Zuweisen usw.). Ich habe jedoch kaum einen anderen Entwickler gesehen, der einen Fehler eingegeben hat. (Warum ist das so?)

79
JoelFan

Wenn Sie einen Fehler entdecken, fällt mir kein guter Grund ein nicht, ihn in das Fehlerverfolgungssystem einzugeben, unabhängig davon, ob Sie ihn beheben oder nicht. Dafür ist das Bug-Tracking-System schließlich da.

In einigen Fällen ist es möglicherweise sinnvoller, dies einer QS-Person zu melden, die mehr Erfahrung im Umgang mit dem System hat. In jedem Fall sollte der Fehler jedoch nachverfolgt werden.

Es ist möglich, dass es einen gültigen oder nicht gültigen Grund gibt, warum Entwickler keine Fehler eingeben sollten. Ein möglicher Grund könnte sein, dass das Fehlerverfolgungssystem für Außenstehende sichtbar ist und zu viele gemeldete Fehler schlecht aussehen. Das ist ein sehr schlechter Grund, der auf eine andere Weise behoben werden sollte, die es immer noch ermöglicht, Fehler zu verfolgen. Fragen Sie Ihren Chef.

(Wenn es einen Fehler im Code gibt, an dem Sie noch arbeiten, und der in nichts, was veröffentlicht wurde, auftaucht, müssen Sie ihn natürlich nicht im System nachverfolgen, obwohl ein TODO-Kommentar im Quellcode möglicherweise vorhanden ist Eine gute Idee. Im Extremfall ist "Dieser Code wird nicht kompiliert, da ich das Semikolon am Ende dieser Zeile noch nicht eingegeben habe" kein meldepflichtiger Fehler.)

Warum andere Entwickler keine Fehler eingeben, müssen Sie fragen. Sie sollten es wahrscheinlich tun.

119
Keith Thompson

In beiden Fällen müssen Sie die Fehler in das Fehlerverfolgungssystem eingeben:

  • wenn der Fehler direkt den Code betrifft, an dem Sie arbeiten,

  • wenn der Fehler den Code betrifft, an dem Sie gerade nicht arbeiten, oder den Teil, an dem ein anderer Entwickler arbeitet.

Dies ist wichtig, da das Fehlerverfolgungssystem dazu dient, ... Fehler zu verfolgen. Jeder Fehler. Wenn Sie etwas falsch entdecken, beheben Sie es nicht einfach. Dokumentieren Sie es über das Bug-Tracking-System. Wenn später ein Kunde, der eine frühere Version der Software ausführt, einen Fehler meldet, bei dem es sich um ein genaues Duplikat handelt, können Sie ihn mit Ihrem Bericht verknüpfen. Wenn Sie nichts zu verlinken haben, verschwenden Sie Ihre Zeit (oder Ihren Kollegen) damit, in früheren Revisionen nach dem Fehler zu suchen. Versuchen Sie dann, ihn zu beheben, und stellen Sie schließlich fest, dass der Fehler bereits auf magische Weise behoben wurde.

Dies erklärt auch, warum Freiberufler sowohl die Versionskontrolle als auch das Bug-Tracking-System verwenden müssen: Diese beiden Tools sind nicht nur für Teams gedacht.

23

Es gibt keinen gültigen Grund, einen Fehler nicht in das Fehlerverfolgungssystem einzugeben. Die einzigen Stellen, an denen Fehlerbehebungen ohne Nachverfolgung angewendet wurden, sind, weil der Prozess grundlegend unterbrochen wurde. Wenn dies der Fall ist, beheben Sie den Vorgang.

gründe für die Nichteinreise sind:

  • Der Prozess misst und bestraft basierend auf der Fehlerberichterstattung - nicht melden, nicht bestraft werden. In diesem Fall verlassen Sie die Organisation
  • Der Prozess ist eine Belastung - es erfordert zu viel Aufwand und Zeit, um einen Fehler einzugeben und ihn zu beheben. Der Prozess sollte geändert werden, damit Entwickler einen leichten Fehler schnell durch den Triage/Accept/Fixed-Prozess verfolgen können.
  • Einige Entwickler sind faul/schlampig/Hacker, denen es egal ist, wie sich die Dinge auswirken, die sie auf andere tun. Rekrutieren Sie professionelle Entwickler.
  • Ich bin eine Ein-Mann-Band, verstehe den Punkt nicht. Gehen Sie für eine 2-Mann-Band arbeiten und Sie werden ...
18
mattnz

Es ist wahrscheinlich eine schlechte Idee, den Fehler sofort zu beheben. Erstens arbeitet möglicherweise jemand anderes an demselben Fix, was zu doppeltem Aufwand führt. Abhängig von der von Ihnen verfolgten Entwicklungsmethode ist es eher eine Priorität, die nächsten Schritte zu priorisieren (Beheben eines Fehlers oder Implementieren einer neuen Funktion) Managemententscheidung dann eine Entwicklungsentscheidung.

14
Daniel Serodio

Die Entscheidung ist nicht eindeutig und beinhaltet Kompromisse.

(einige) PROS

Die Fehlerverfolgung ist für die Kommunikation von entscheidender Bedeutung, insbesondere in großen Teams. Einer der besten Vorteile mehrerer Augen für den Code ist die Möglichkeit, Probleme früher zu erkennen. Dieser Vorteil geht verloren, wenn Fehler während der Entwicklung nicht protokolliert oder nachverfolgt werden.

  • Oft lassen sich Fehler am einfachsten beheben, wenn Sie sich bereits in einem Teil des Codes befinden und daran arbeiten, ihn zu verstehen.
  • Selbst in kleineren Teams ist es moralisch sehr vorteilhaft, Fehler aufzulisten und Fortschritte bei der Behebung zu erzielen - manchmal ist der moralische Vorteil selbst bei Ein-Mann-Projekten von entscheidender Bedeutung.
  • Eine genaue Fehlererkennung kann im Nachhinein sehr schwierig sein - das Erkennen eines Fehlers im Code kann viel spätere Arbeit beim Erkennen von Detektiven ersparen und versuchen, herauszufinden, wo das Problem ursprünglich aufgetreten ist.
  • Es ist gut für Ihre allgemeine Entwicklung als Entwickler, auf Fehler zu achten, wenn Sie sie sehen, und sich daran zu gewöhnen, Code kritisch zu verbessern/zu bereinigen/zu lesen

Das Protokollieren von Fehlern, wie Sie sie finden, ist im Allgemeinen eine gute Angewohnheit.

(einige) CONS

Das Eingeben von Fehlern in ein Fehlerverfolgungssystem kann lästig und zeitaufwändig sein und die Entwicklungsarbeit erheblich stören - häufiger, wenn Sie in großen Teams arbeiten. Es kann erwartet werden, dass Sie:

  • überprüfen Sie vor der Eingabe, ob es sich bei Ihrem Eintrag um ein Duplikat handelt (dies kann sogar implizit sein. Es ist nicht empfehlenswert, Ihren Fehler in die Warteschlange einzutragen, um ihn zu schließen.)
  • geben Sie wiederholbare Testfälle für Ihren Bericht an
  • akzeptieren Sie spätere Unterbrechungen mit Fragen zu Fehlerdetails, um eine Korrektur beim Schreiben zu akzeptieren/zu überprüfen
  • denken Sie an nicht verwandte Informationen, die häufig in Fehlerverfolgungssystemen gesammelt werden, z. B. welches Produkt wahrscheinlich am stärksten betroffen ist, die Priorität des Fehlers usw.

Manchmal ist Bug Tracking einfach nicht die effizienteste Nutzung Ihrer Zeit.


Dies sind zwei allgemeine Prinzipien, die schwer in Einklang zu bringen sind - eine gute Strategie zu finden, ist eine Kunst. In solchen Situationen ist es meiner Meinung nach am besten, eine flexible Heuristik zu verwenden, die ich je nach Bedarf für ein bestimmtes Projekt, Team, Arbeitsumfeld und Ihre allgemeinen Fähigkeiten anpasse. Meine Strategie folgt normalerweise einem Muster wie ungefähr:

  • Protokollieren Sie Probleme immer so, wie Sie sie im Laufe Ihres Tages irgendwo sehen. Vielleicht auf einem Sticky, vielleicht in einer Datei zur Seite. Vielleicht protokollieren Sie nur einen Dateinamen und eine Zeilennummer, vielleicht mehr. Lassen Sie das Problem Ihre aktuelle Denkrichtung nicht zu sehr unterbrechen.
  • Nehmen Sie sich zu Beginn jedes neuen Arbeitstages Zeit, um sich mit den Stickies zu befassen. Ich nehme mir 10 bis 15 Minuten Zeit, um meine Liste der erkannten Probleme vom Vortag durchzugehen und die schnellsten Schritte auszuführen:

    • Beheben Sie das Problem und legen Sie es fest (wahrscheinlich für Einzeiler-Korrekturen oder Tippfehler). Wenn Sie ohne Fehlerbericht kein Commit durchführen dürfen, erstellen Sie ein Nebenprojekt für kleine Commits. Wenn sich im Nebenprojekt genügend Korrekturen angesammelt haben, nehmen Sie sich die wenigen Stunden Zeit, um diese zu dokumentieren und festzuschreiben.
    • Protokollieren Sie das Problem in einem Fehlerverfolgungssystem (für offensichtliche Probleme, deren Behebung länger dauert, jedoch ohne lästigen Overhead)
    • Protokollieren Sie das Problem in einem Dokument "Zum Anschauen, wenn es nicht beschäftigt ist" (normalerweise füge ich der Quelle einen Kommentar vom Typ "// TODO - das sieht kaputt aus, beheben Sie es" hinzu). Nehmen Sie sich regelmäßig einen Tag Zeit (ich versuche es einmal im Monat), um die Liste durchzugehen und sie entsprechend zu protokollieren - Funktionsanforderung, Fehlerbericht, Diskussion mit dem Manager usw.

Im Laufe der Zeit habe ich alle möglichen Verbesserungen als nützlich empfunden. Zum Beispiel:

  • In starreren Umgebungen verlagere ich die Fehlerberichterstattung möglicherweise einfach an das Testteam. Lassen Sie sich von Zeit zu Zeit von einem Tester für eine Stunde treffen, geben Sie ihm die Liste der Probleme und lassen Sie ihn die Protokollierung durchführen. In Umgebungen, in denen Protokollierungstests eine große Rolle spielen, freut sich der Tester normalerweise über die kostenlose Steigerung seiner Produktivität.
  • Einige Teams lehnen es ab, Korrekturen zuzulassen, hinter denen kein Kundenfehlerbericht steht. Ich würde ein Projekt voller Korrekturen auf der Seite halten und sie sofort festschreiben, wenn das relevante Problem von einem Kunden gemeldet wird, für kostenlose Brownie-Punkte.
  • Einige Teams verlangen, dass die Person, die einen Teil des Codes "besitzt", die Korrekturen durchführt. Ich würde den Code "Eigentümer" wie einen Testleiter behandeln und mich informell treffen, um gelegentlich Probleme zu lösen

Ich stelle fest, dass im Allgemeinen, wenn Sie diese Art von Strategie verfolgen, immer mehr Ihrer Kollegen und anderen Unternehmensmitglieder beginnen, Ihre Arbeit und Ihr Engagement für Qualität zu respektieren. Nach einiger Zeit haben Sie den nötigen Respekt und die nötige Autorität, um den gesamten Prozess nach Ihren Wünschen zu optimieren. Halten Sie Ausschau nach solchen Möglichkeiten und nutzen Sie sie gegebenenfalls.

12
blueberryfields

Ich glaube, wenn ein Entwickler auf einen Fehler stößt, der nicht mit seiner Arbeit zusammenhängt und den er nicht behebt, sollte er ihn in das System eingeben, nur um einige Aufzeichnungen darüber zu haben. Wenn die Qualitätssicherung mit dem Testen beginnt (und sie immer noch nicht behoben sind), können Sie ihnen diese Listenfehler als "bekannte Fehler" zuweisen, damit sie nicht dieselben Fehler melden.

Vielleicht behalten andere Entwickler, die Fehler finden, diese selbst in der Hand, wenn sie sie beheben möchten. In diesem Fall laufen sie jedoch Gefahr, dass zwei Entwickler unabhängig voneinander denselben Fehler finden und beheben.

Ich würde hinzufügen, dass es eine gute Idee ist, den Fehler zu verfolgen, auch wenn er bereits behoben wurde (was vor der Aufzeichnung in einem Issue-Tracker nicht hätte passieren dürfen).

Auf diese Weise ist es relativ einfach, das Problem als "bereits behandelt" zu erkennen und zu lesen, wie es beim ersten Mal behoben wurde, falls das Problem in Zukunft erneut auftreten sollte (Regressionen treten auf!).

2
fdierre

Warum ist das so? Da sich die meisten Entwickler das Problem ansehen, das sie ansprechen müssen, und den Code, den sie schreiben und herausfinden müssen, ist es einfacher, sich nicht darum zu kümmern.

Ob dies jedoch richtig ist, hängt von Ihrem Prozess ab. Haben Sie ein QS-Team? Denken Sie, dass es ihnen etwas ausmacht, wenn Sie nur Code ändern, der nicht verfolgt wird? Was ist mit Code-Reviews? Wird es diesen Riss überspringen? Was ist mit dem Geschäft? Müssen sie wissen, dass Sie einen Fehler behoben haben, damit sie diesen später nicht mehr auslösen?

Was ist mit anderen Entwicklern? Was ist, wenn sie es gleichzeitig auf eine andere Weise beheben? Was ist, wenn sie später einen ähnlichen Fehler finden und Sie nur sagen können: "Oh, verdammt, ich weiß, wir hatten so etwas schon einmal - was war es jetzt?"

Es gibt ungefähr eine Million Gründe, Fehler im Fehlerverfolgungssystem aufzuzeichnen. Wenn Sie sicher sind, dass Sie keines dieser Probleme haben, stören Sie sich auf keinen Fall. Aber wenn Sie sich überhaupt nicht sicher sind, sollten Sie es aufnehmen, auch wenn die meisten Leute es nicht tun.

1
pdr

Natürlich sollten Sie es eingeben. Oder melden Sie es zumindest Ihren QS-Mitarbeitern, wenn dies Ihr normaler Prozess ist.

Selbst wenn Sie den Fehler nur selbst beheben, möchten Sie eine Aufzeichnung der Änderung, damit diese getestet werden kann, um sicherzustellen, dass die Korrektur tatsächlich funktioniert und keine Regression stattgefunden hat. Es ist auch möglich, dass ein Benutzer den Fehler irgendwann meldet. Wenn er sich im System befindet und als behoben markiert ist, können Ihre Support-Mitarbeiter ihm mitteilen, dass er bereits behoben wurde.

1
GrandmasterB

Die Programmierung ist grundsätzlich eine komplexe Arbeit. Die Fehler sind komplex. Deshalb habe ich einen Fehler anhand von zwei Faktoren bewertet:

  1. Wie oft können solche Fehler in Zukunft erneut auftreten? Ob diese Schätzung korrekt ist oder nicht, schätzen Sie weiter.
  2. Wenn solche Fehler erneut auftreten, ist es leicht zu verstehen? Dies ist genau, wenn Sie diesen Fehler analysieren und beheben.

Ich würde einen Fehler in einen der folgenden Typen einteilen:

  1. Erscheint wahrscheinlich in Zukunft wieder und ist leicht zu verstehen
  2. Erscheint wahrscheinlich in Zukunft wieder, ist aber schwer zu verstehen
  3. Erscheint in Zukunft selten wieder und ist leicht zu verstehen
  4. Erscheint in Zukunft selten wieder, ist aber schwer zu verstehen

In Fall 1 ist ein Kochbuch oder FAQ ein gutes Gerät für das Team, um solche Fehler in Zukunft zu beheben.

In Fall 2 ist eine ausführliche und verständliche Aufzeichnung für das Team erforderlich, da es eine Verschwendung von Aufwand ist, wenn ein anderer Programmierer solche Fehler erneut erträgt. Zum Beispiel: Speicherverlust.

In Fall 3 ist es meiner Meinung nach keine große Sache, dass nichts mehr aufgezeichnet werden kann, da Sie nicht zu viel Zeit damit verbringen, einen einfachen Fehler zu beheben. Zum Beispiel ein Tippfehler für die ID des Elements in HTML.

In Fall 4 verursachen solche Fehler ein Dilemma. Es braucht einige Zeit, um eine ausführliche und verständliche Aufzeichnung zu schreiben, um solche Fehler zu beschreiben. Diese Aufzeichnung wird jedoch in Zukunft nur noch selten verwendet. Ohne eine Aufzeichnung wäre das Auftreten solcher Fehler jedoch wieder ein Kampf. Solche Fehler treten beispielsweise aufgrund von Computerviren auf dem Computer eines anderen Benutzers auf.

1
Mike Lue

Wenn Sie etwas sehen, dann sagen Sie etwas!

Ich gebe sogar Fehlerberichte über meine eigenen Module ein, weil ich meine aktuelle Aufgabe nicht unterbrechen möchte. Und ich kann sicherstellen, dass alle Schritte zur Reproduktion enthalten sind :-)

Und es ist noch besser, wenn jemand anderes sieht, dass Sie etwas als bekannten Fehler aufgelistet haben. Sie möchten wissen, dass es auch jemand anderes gefunden hat.

0
jqa

In der Tat sollten Sie sie im System aufzeichnen, und falls es nicht geübt wird, ist es gut, anzufangen.

In meiner Vergangenheit war ich Teil eines Produktteams, und wir befanden uns in der Beta-Version eines neuen Produkts. Manchmal fanden wir gelegentlich Fehler, die wir zu diesem Zeitpunkt notierten und an die jeweiligen Personen schickten, die die Module handhabten (die wir hatten) ein Bug-Tracking-System, aber wir haben nicht daran gedacht, sie dorthin zu bringen). Später, als die Tage vergingen, wurden die Artikel in der Post aufgrund anderer Prioritäten ignoriert, was schließlich zu schlaflosen Nächten führte.

Dann knall eines Tages, Nirvana! Warum verwenden wir den Bug-Tracker nicht, auch wenn Sie etwas gefunden haben, das wie ein Bug aussieht und möglicherweise nicht vorhanden ist (Ihr Gedanke an den Prozess ist falsch/fehlerhaft). Es macht zumindest auf der Liste, die dann getestet werden könnte, und am wichtigsten von allem ein Feedback, warum es kritisch ist oder auf der anderen Seite ist es perfekt und so sollte es aus Gründen 1 funktionieren ... 2 ....

Jetzt haben Sie die Liste und auch für diejenigen, die einige Teile der Anwendung missverstanden haben, haben sie das Feedback, auf dessen Grundlage sie ihre Gedanken klären können. Eine win-win Situation.

0
V4Vendetta

Ich denke, dies ist eher eine politische Frage als eine Frage zur besten Praxis.

  • beschuldigt der Bug-Eintrag jemanden?
  • kann der Kunde Fehlereinträge lesen und sieht, dass es zusätzliche Fehler gibt. Ist dies ein Reputationsproblem für Ihr Unternehmen?
  • ist dies wirklich ein Fehler oder eine Funktion, die Sie nicht kennen?
  • wer bezahlt den Bugfix?

Meiner Meinung nach ist es eine gute Praxis, nicht triviale Fehler in das Trackersystem einzufügen, aber das Management muss entscheiden, wie damit umgegangen werden soll.

In nicht trivialen Fällen sollten Sie das Problem nicht beheben, ohne jemanden zu konsultieren, um dies sicherzustellen

  • dies ist wirklich ein Fehler und keine Funktion
  • jemand anderes kann das Update testen und sicherstellen, dass das Update keinen neuen Fehler verursacht (Regression)
0
k3b

Vorausgesetzt, der bereits getestete (und insbesondere freigegebene) Code ist absolut.

Dafür gibt es eine Reihe von Gründen:

Speicher - Es ist sehr unwahrscheinlich, dass das System den Fehler vergisst.

Metriken - Die Anzahl der gefundenen, geschlossenen Fehler und die benötigte Zeit können gute, einfach zu erfassende Metriken sein, mit denen Sie feststellen können, wie sich die Qualität Ihres Codes entwickelt

Dringlichkeit - Für den Entwickler scheint dies das Wichtigste auf der Welt zu sein. Die Zeit, die für die Behebung dieses Problems aufgewendet wird, kann jedoch besser für etwas verwendet werden, das die Endbenutzer zuerst wünschen (siehe auch Speicher).

Vervielfältigung - Vielleicht wurde es bereits entdeckt und wird von jemand anderem untersucht/repariert. Alternativ ist es möglicherweise gegen die Dringlichkeitsregel verstoßen und verschoben worden. Natürlich bedeutet die Tatsache, dass Sie es wiedergefunden haben, nicht nur, dass es nicht getan werden sollte, es könnte auch bedeuten, dass es (da es immer wieder auftaucht) jetzt dringender ist, es zu beheben.

rsachenanalyse - Der am einfachsten zu behebende Fehler ist der, der nie vorhanden war. Es kann sein, dass das Team diesen Fehler untersucht, um herauszufinden, wie er entstanden ist. Dies ist definitiv nicht, um den Verantwortlichen zu bestrafen (das hilft nie), sondern um herauszufinden, wie die Situation in Zukunft vermieden werden kann.

mfassendere Auswirkungsanalyse - Der billigste Fehler, um zu finden, ist der, von dem Sie wussten, bevor Sie ihn gefunden haben. Wenn Sie sich diesen Fehler ansehen (insbesondere nach der Ursachenanalyse), wird schnell klar, dass dieses Problem an anderen Stellen im Code auftreten kann. Infolgedessen kann das Team entscheiden, es zu suchen, bevor es in einem peinlicheren Moment seinen hässlichen Kopf hebt.

Die dafür aufgewendete Zeit (falls vorhanden) hängt weitgehend von der Reife und dem Qualitätsniveau des Codes ab. Die Ursachenanalyse ist für ein kleines Team, das an Demonstrationscode arbeitet, wahrscheinlich übertrieben, aber ein großes Team für geschäftskritische Entwicklung muss die Lektionen wahrscheinlich effektiv und effizient lernen.

Erfahrungsgemäß vermeiden Entwickler das Tool aus zwei Gründen:

  1. Das Tool und/oder der Prozess zur Fehlerbehandlung wird als zu schwer für die Entwicklung angesehen
  2. Die Entwickler finden die mentale Herausforderung, den Fehler zu beheben, interessanter als die Dinge, an denen sie gerade arbeiten.

Punkt 1 impliziert, dass ein besseres/einfacheres System erforderlich sein kann; oder alternativ könnte eine überzeugendere Rechtfertigung des bestehenden Systems angebracht sein.

Punkt 2 sollte ein nützliches Warnzeichen für den Entwicklungsleiter bezüglich der aktuellen Aufgabenzuweisungen sein.

0
Gavin H

Ich stimme FrustratedWithFormsDesign größtenteils zu, aber ich denke, es ist noch klarer, wenn das gesamte Problem in zwei Bereiche unterteilt wird:

  • Fehlerberichterstattung.
  • Bugfixing.

Diese werden oft als gleich behandelt und ihre Trennung wird mit ziemlicher Sicherheit sehr hilfreich sein.

Diese können behandelt werden mit: Fehlerberichterstattung: - Legen Sie es in das System, wie jeder sagt.

Fehlerbehebung: - Alle ein oder zwei Wochen (Anpassung an Ihren Entwicklungsplan usw.) kommen alle zum Projekt zusammen und entscheiden, was von wem usw. behoben werden soll. Dies war, dass jeder auf derselben Seite ist und sehen kann, was erforderlich ist getan werden. In Agile Development ist dies das Sprint Planning-Meeting.

Ein gutes Werkzeug, das die Leute wollen verwenden, macht auch einen großen Unterschied. Ich mag Pivotal Tracker und es hat meinen 'wirklich nützlichen Tool'-Test bestanden, als ich anfing, es zu verwenden, nur um den Überblick zu behalten, was ich in meinen eigenen privaten Projekten tun oder reparieren möchte!

0
junky