Sollten Entwickler Fehler in das Fehlerverfolgungssystem eingeben?

76

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

Ich gebe es in der Regel in das Bug-Tracking-System ein und lasse den Prozess von selbst ablaufen (z. B. Testen, Zuweisen usw.). Allerdings habe ich kaum einen anderen Entwickler gesehen, der einen Fehler gemeldet hat. (Warum ist das so?)

JoelFan
quelle
48
Warum würdest du sie nicht betreten? Haben Sie Ihre Kollegen gefragt, warum sie das nicht tun?
ChrisF
23
Ja, das sollten sie. Zeitraum.
Pop Catalin
6
Vielleicht ist das Problem, dass sie es als " jemand anderes Bug-System " betrachten.
Xeoncross
6
Geben Sie es ein, es sei denn, es gibt ein Mandat, das Sie nicht erteilen sollen. Wenn Sie Code einchecken, ist es im Allgemeinen eine gute Idee, das Einchecken mit einem Arbeitselement zu verknüpfen. Außerdem habe ich ein paar Stellen gesehen, an denen jemand einen Fehler entdeckt, davon ausgeht, dass es sich um ein bekanntes Problem handelt, und nie jemandem davon erzählt. Das willst du nicht.
JSWork
4
Sofern es sich nicht um eine einfache und offensichtliche Änderung handelt, sollten Sie nicht versuchen, sie zu beheben. Indem Sie Ihrem aktuellen Fix ein weiteres Verschiebungselement hinzufügen, können Sie Dinge viel unhandlicher machen. Sie sollten es unbedingt protokollieren, um die entsprechende Aufmerksamkeit zu erhalten. Dh Wenn Sie das Problem beheben, ohne ein Ticket dafür zu protokollieren, weiß die Qualitätssicherung nicht, ob Sie es testen können, und Sie können möglicherweise ein noch größeres Problem einführen. Das ist gefährlich. Andere Entwickler wissen es vielleicht nicht besser ... Sie sollten es ansprechen.
Sam yi

Antworten:

118

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

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

Es ist möglich, dass es einen Grund gibt, der gültig ist oder nicht, dass Entwickler keine Fehler eintragen 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 angegangen werden sollte, die es weiterhin ermöglicht, Fehler zu verfolgen. Fragen Sie Ihren Chef.

(Wenn es einen Fehler im Code gibt, an dem Sie noch arbeiten und der in keiner veröffentlichten Version auftaucht, müssen Sie ihn natürlich nicht im System nachverfolgen, auch wenn es sich möglicherweise um einen TODO-Kommentar im Quellcode handelt 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.)

Wenn Sie wissen möchten, warum andere Entwickler keine Bugs eintragen, müssen Sie sie fragen. Sie sollten es wahrscheinlich tun.

Keith Thompson
quelle
15
Außerdem können Sie nachverfolgen, auf welche Fehler Sie stoßen, Komponententests schreiben und Regressionstests zu diesem Verhalten durchführen, selbst wenn es sich um eine einfache Lösung handelt. Sie wissen nie, wann jemand zurückkehrt und es wieder unterbricht, und dann bekommen Sie deja vu, wenn Sie darüber nachdenken, warum sich der Fehler so vertraut anfühlt, und dann haben Sie keine Fehlernummer, auf die Sie verweisen können. Nicht wie ich es wissen würde ...
wkl
Im Allgemeinen wird ein vom Entwicklungsteam und nicht vom Kunden festgestellter Fehler als "bekanntes Problem" bezeichnet. Ob dieses Problem jemals behoben werden wird oder nicht, steht ebenso wie "Bugs" zur Debatte. Die Konnotation lautet jedoch, dass das Entwicklerteam weiß, dass dies ein Problem ist. Daher sollte der Kunde keinen "Bug" für denselben Fehler oder dasselbe Problem melden . Allerdings ist es für das Entwicklerteam völlig angemessen, Fehler in Bereichen von Software zu protokollieren, die nichts mit dem zu tun haben, was sie gerade codieren. Es wäre ein bisschen albern, einen Fehler im Code, den Sie entwickeln, zu protokollieren (es sei denn, Sie werden durch den Fehler a la Dilbert bezahlt).
KeithS
3
@KeithS: Wenn es sich um einen Fehler im Code handelt, an dem Sie noch arbeiten, wäre es dumm, ihn zu melden. Wenn es sich um einen Fehler handelt, der in einem veröffentlichten Produkt vorkommt, sollte dieser gemeldet werden, auch wenn es sich um Code handelt, den Sie gerade reparieren möchten. Ein Fehlerbericht ist auch dann wertvoll, wenn Sie ihn unmittelbar nach dem Öffnen schließen (obwohl "Schließen" in der Regel mehrere Statusübergänge abdeckt).
Keith Thompson
2
Das andere, was zu tun ist, ist sicherzustellen, dass jemand über den Fehler Bescheid weiß. Wenn Ihre Teamleiter alle neuen Probleme anzeigen, sobald sie eintreffen, ist dies bereits geregelt. Wenn Sie jedoch wissen, dass das Problem eine Weile nicht mehr angezeigt wird, müssen Sie wissen, wer für die Priorisierung der Arbeit verantwortlich ist Stellen Sie sicher, dass das Problem behoben wird. Ihr tägliches Stand-up-Meeting oder Ihre regelmäßigen Teammeetings können ein guter Ort sein, um diese Dinge anzukündigen, oder Sie können Ihrem Teamleiter eine E-Mail senden, wenn Ihr Issue-Tracking-System dies nicht bereits für Sie erledigt.
S.Robins
1
@ S.Robins: Ja, aber wenn die Eingabe eines Fehlers im Tracking-System nicht sicher ist, dass jemand davon weiß, funktioniert Ihr Tracking-System nicht sehr gut.
Keith Thompson
23

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 von wesentlicher Bedeutung, da das Bug-Tracking-System ... zur Verfolgung von Bugs dient. Jeder Fehler. Wenn Sie einen Fehler entdecken, beheben Sie ihn nicht einfach. Dokumentieren Sie es über das Bug-Tracking-System. Wenn ein Kunde, der eine frühere Version der Software ausführt, später 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, nach dem Fehler in früheren Versionen 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 Fehlerverfolgungssystem verwenden müssen: Diese beiden Tools sind nicht nur für Teams gedacht.

Arseni Mourzenko
quelle
1
Sie machen einen sehr guten Punkt, vorausgesetzt, der Fehler ist in einer früheren Version vorhanden.
Karl Bielefeldt
2
Mmm. Sicher nicht jeder Käfer. Angenommen, Sie lesen einen Code, den Sie gerade geschrieben haben, und Sie finden einen Fehler in einer Schleife in der Nähe, sagen wir. Oder ein Tippfehler. Das Schreiben des Fehlers dauert länger als das Beheben des Fehlers, insbesondere wenn sich der Code noch in der Entwicklung befindet.
Zan Lynx
2
@ZanLynx In diesen Fällen sollten Sie an einem offenen Fehlerbericht oder einer Funktionsanforderung arbeiten. Wenn es zum Testen freigegeben wurde, öffnen Sie es erneut und fügen Sie eine entsprechende Notiz hinzu.
BillThor
18

Es gibt keinen triftigen Grund, einen Fehler nicht in das Fehlerverfolgungssystem einzutragen. Die einzigen Stellen, an denen ich Fehlerbehebungen ohne Nachverfolgung gesehen habe, sind die, weil der Prozess grundlegend fehlerhaft war. Wenn dies der Fall ist, beheben Sie den Vorgang.

Gründe für die Nichteinreise sind:

  • Der Prozess misst und bestraft basierend auf der Meldung von Fehlern - nicht melden, nicht bestraft werden. In diesem Fall verlassen Sie die Organisation
  • Der Prozess ist eine Belastung - es ist zu aufwändig und zu zeitaufwändig, einen Fehler zu erfassen und ihn zu beheben. Der Prozess sollte geändert werden, damit Entwickler einen leichten Fehler durch den Triage / Accept / Fixed-Prozess schnell nachverfolgen können.
  • Einige Entwickler sind faul / schlampig / Hacker, denen es egal ist, wie sich die Aktionen auf andere auswirken. 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 ...
mattnz
quelle
Ich vermute, dass Ihr zweiter Punkt oft der Grund ist. Hat XP nicht für die Idee geworben, nur Fehler zu beheben, anstatt einen Prozess zu durchlaufen? Dies ist praktisch ein schneller Weg für einen leichten Fehler. <sarcasm> außer Regressionstests wird
feststellen,
2
@phkahlr: Ich stimme zu, jedes System verfügt über robuste Regressionstests, die sicherstellen, dass die perfekt spezifizierten Anforderungen erfüllt werden und die Kunden nie unspezifizierte Funktionen verwenden. Die aktuellen Entwickler schreiben jedes Mal perfekten Code, sodass keine Möglichkeit besteht, dass ein Bugfix unerwünschte Nebenwirkungen hervorruft. Ich diese Welt, "nur reparieren" könnte Approrite sein. In meiner Welt, in der es Millionen von Zeilen mit eingeschränkten Regressionstests gibt, die ein lebenskritisches Legacy-System implementieren, werde ich wahrscheinlich einem Prozess folgen.
Mattnz
14

Es ist wahrscheinlich eine schlechte Idee, den Fehler sofort zu beheben. Erstens arbeitet möglicherweise eine andere Person an derselben Fehlerbehebung, was zu doppeltem Aufwand führt, und je nach der von Ihnen angewendeten Entwicklungsmethode ist es vorrangig, was als Nächstes zu tun ist (Beheben eines Fehlers oder Implementieren einer neuen Funktion) Managemententscheidung dann eine Entwicklungsentscheidung.

Daniel Serodio
quelle
5
Dies setzt ein großes Team und eine Umgebung voraus, in der Programmierer keine Entscheidungen treffen müssen. Wenn es nur eine Handvoll Entwickler gibt und Sie Ihren Stuhl herumdrehen und sagen können: "Hey, arbeitet jemand an X", gibt es keinen besonderen Grund, den Fehler nicht sofort zu beheben (wenn es die Zeit erlaubt).
GrandmasterB
Aber es kommt auf die Priorität an, oder? Das bedeutet, dass sich die Aufgabe, an der Sie gearbeitet haben, möglicherweise verzögert. Es kann auch Ihren Fluss unterbrechen.
JoelFan
1
@JoelFan: Flow ist bereits unterbrochen. Mein Fluss würde mehr unterbrochen, wenn ich wüsste, dass es einen nicht behobenen Fehler gibt.
Zan Lynx
3
@GrandmasterB Da wir bereits über Flow sprechen, möchte ich nicht alle anderen Entwickler so stören. Wenn Sie auf einen Fehler stoßen, melden Sie ihn und lassen Sie die anderen darauf schauen, wenn sie Zeit haben. Das ist viel besser für alle, als sie dazu zu bringen, das zu tun, was sie tun, nur damit Sie allen den Fehler erklären können und nur um herauszufinden, dass wahrscheinlich niemand daran arbeitet und sie alle unterbrochen werden, ohne dass ein Ergebnis für diesen Fehler vorliegt …
24.02.12
+1 für das Management, das Ihre Bemühungen leitet. Ich habe kürzlich gelernt, es zu dokumentieren und weiterzumachen, anstatt 2x meine ursprüngliche Schätzung auszugeben, um alles zu reparieren, was mir begegnet.
mskfisher
12

Die Entscheidung ist nicht eindeutig und beinhaltet Kompromisse.

(einige) PROS

Die Verfolgung von Fehlern ist für die Kommunikation von entscheidender Bedeutung, insbesondere bei großen Teams. Einer der besten Vorteile, wenn Sie mehrere Augen auf den Code haben, ist die Fähigkeit, Probleme früher zu erkennen. Dieser Vorteil geht verloren, wenn Fehler während der Entwicklung nicht protokolliert oder nachverfolgt werden.

  • Häufig lassen sich Fehler am einfachsten beheben, während Sie sich bereits in einem Teil des Codes befinden und daran arbeiten, ihn zu verstehen.
  • Sogar in kleineren Teams ist es moralisch gesehen von großem Vorteil, Fehler aufzulisten und Fortschritte bei deren Behebung zu erzielen. Manchmal ist der moralische Vorteil sogar bei Ein-Mann-Projekten von entscheidender Bedeutung.
  • Eine genaue Fehlererkennung kann nachträglich sehr schwierig sein - das Erkennen eines Programmfehlers kann eine Menge späterer Arbeit als Detektiv ersparen, um 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 oder 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 zeitaufwendig sein und die Entwicklungsarbeit erheblich beeinträchtigen - 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 daher nicht ratsam, 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 einen Fix beim Schreiben zu akzeptieren / zu überprüfen
  • Denken Sie an nicht verwandte Informationen, die häufig in Bug-Tracking-Systemen gesammelt werden, z. B. welches Produkt wahrscheinlich am stärksten betroffen ist, welche Priorität der Bug hat usw.

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


Dies sind zwei allgemeine Prinzipien, die sich nur schwer ausbalancieren lassen - eine gute Strategie zu finden ist eine Kunst. In solchen Situationen ist es meines Erachtens am besten, eine flexible Heuristik anzuwenden, die ich für ein bestimmtes Projekt, Team, Arbeitsumfeld und Ihre allgemeinen Fähigkeiten anpasse. Meine Strategie folgt normalerweise ungefähr dem folgenden Muster:

  • Protokollieren Sie Probleme immer so, wie Sie sie im Laufe des Tages sehen, irgendwo. Vielleicht klebrig, vielleicht in einer Akte zur Seite. Vielleicht ist alles, was Sie protokollieren, ein Dateiname und eine Zeilennummer, vielleicht mehr. Lassen Sie sich nicht zu sehr von dem Problem unterbrechen.
  • Nehmen Sie sich zu Beginn eines jeden neuen Arbeitstages Zeit, um sich im Rahmen Ihrer Vorbereitung auf die Arbeit mit den Stickies zu befassen. Ich nehme mir 10-15 Minuten Zeit, um meine Liste der erkannten Probleme vom Vortag durchzugehen, und tue, was am schnellsten ist:

    • Beheben Sie das Problem und schreiben Sie es fest (wahrscheinlich für einzeilige 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 einige Stunden Zeit, um sie zu dokumentieren und festzuschreiben.
    • Protokollieren Sie das Problem in einem Bug-Tracking-System (für offensichtliche Probleme, deren Behebung länger dauert, aber ohne lästigen Aufwand).
    • Protokollieren Sie das Problem in einem Dokument, in dem Sie nachsehen können, wann es nicht beschäftigt ist (normalerweise füge ich einen Kommentar vom Typ "// TODO - das sieht kaputt aus, korrigieren Sie es" zur Quelle hinzu). Nehmen Sie sich regelmäßig einen Tag Zeit (ich versuche es einmal im Monat), um die Liste nach Bedarf zu durchsuchen und zu protokollieren - Funktionsanforderung, Fehlerbericht, Besprechung mit dem Manager usw.

Im Laufe der Zeit habe ich alle möglichen Verbesserungen für nützlich befunden. Zum Beispiel:

  • In starren Umgebungen kann ich die Fehlerberichterstattung einfach an das Testteam auslagern. Lassen Sie sich von Zeit zu Zeit von einem Tester für eine Stunde treffen, geben Sie ihm die Liste der Probleme und veranlassen Sie ihn, die Protokollierung durchzufü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, für die kein Kunden-Bug-Report hinterlegt ist. Ich würde ein Projekt voller Korrekturen auf der Seite lassen und diese sofort festschreiben, wenn ein Kunde das entsprechende Problem meldet, und dafür kostenlose Brownie-Punkte erhalten.
  • Einige Teams verlangen, dass die Person, die ein Stück Code "besitzt", diejenige ist, die Korrekturen durchführt. Ich würde den Code "Eigentümer" wie einen Testleiter behandeln und mich zwanglos treffen, um gelegentlich Probleme abzugeben

Ich bin der Meinung, dass im Allgemeinen, wenn Sie diese Art von Strategie verfolgen, immer mehr Kollegen und andere Unternehmensmitglieder beginnen, Ihre Arbeit und Ihre Verpflichtung zur 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 nach solchen Gelegenheiten Ausschau und ergreifen Sie sie entsprechend.

Blaubeerfelder
quelle
2
"Einige Teams lehnen es ab, Korrekturen zuzulassen, für die kein Kunden-Bug-Report hinterlegt ist" ... wirklich? Klingt nach einem DailyWTF! Sie sagen also, dass es einen klaren Fehler geben könnte, der die Kunden definitiv betreffen würde (und möglicherweise hat), und dass sie weiterhin Releases mit dem gleichen, nicht behobenen Fehler veröffentlichen, ohne auch nur die Kosten für die Behebung zu analysieren, nur weil ein Kunde dies nicht getan hat noch nicht gemeldet?
JoelFan
1
"Repariere es nicht, wenn es nicht kaputt ist" ist schief gegangen.
blueberryfields
4

Ich glaube, wenn ein Entwickler einen Fehler trifft , die nicht bezieht , was sie arbeiten und dass sie nicht werden , Festsetzung, sie sie in das System eingeben sollte nur haben einige Aufzeichnungen darüber. Auf diese Weise können Sie QA-Teststarts (und sie sind immer noch nicht behoben) diese Liste mit Fehlern als "bekannte Fehler" kennzeichnen, sodass sie nicht die gleichen Fehler melden.

Vielleicht behalten andere Entwickler, die Fehler finden, diese selbst im Auge, wenn sie beabsichtigen, sie zu beheben, aber in diesem Fall laufen sie Gefahr, dass zwei Entwickler denselben Fehler unabhängig voneinander finden und beheben.

FrustratedWithFormsDesigner
quelle
2

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

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 erneut auftreten sollte (es kommt zu Regressionen!).

fdierre
quelle
1

Warum ist das so? Da sich die meisten Entwickler mit dem Problem befassen, das sie ansprechen müssen, und mit dem Code, den sie schreiben und berechnen 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 QA-Team? Denken Sie, dass es ihnen etwas ausmacht, wenn Sie nur Code ändern, der nicht nachverfolgt 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 ihn 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 noch 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 Bug-Tracking-System aufzuzeichnen. Wenn Sie sicher sind, dass Sie keines dieser Probleme haben, sollten Sie sich nicht darum kümmern. Aber wenn Sie sich nicht sicher sind, sollten Sie es aufzeichnen, auch wenn die meisten Menschen dies nicht tun.

pdr
quelle
1

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

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

Ich würde einen Bug 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 eine häufig gestellte Frage ein gutes Hilfsmittel für das Team, um solche Fehler in Zukunft zu beheben.

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

In Fall 3 ist es meiner Meinung nach keine große Sache, dass nichts mehr aufgezeichnet werden muss, da Sie nicht zu viel Zeit für die Behebung eines einfachen Fehlers aufwenden. 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. Dieser Datensatz wird jedoch in Zukunft nur noch selten verwendet. Ohne eine Aufzeichnung wäre das Auftauchen solcher Fehler jedoch wieder ein Kampf. Solche Fehler treten beispielsweise aufgrund von Computerviren auf dem Computer einer anderen Person auf.

Mike Lue
quelle
1

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

Selbst wenn Sie den Fehler nur selbst beheben, möchten Sie eine Aufzeichnung der Änderung, damit diese dann 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 im System vorhanden und als behoben markiert ist, können Ihre Support-Mitarbeiter ihm mitteilen, dass er bereits behoben wurde.

GrandmasterB
quelle
0

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, und gelegentlich fanden wir Fehler, die wir zu diesem Zeitpunkt notierten und an die jeweiligen Personen schickten, die die Module betreuten (wir hatten) ein Bug-Tracking-System, aber wir dachten nicht daran, sie dorthin zu schieben). Später, als die Tage vergingen, wurden die Postsendungen aufgrund anderer Prioritäten ignoriert, was schließlich zu schlaflosen Nächten führte.

Dann, 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 (Ihre Überlegungen zum Prozess sind falsch / fehlerhaft). Zumindest auf der Liste, die dann getestet werden könnte, und vor allem eine Rückmeldung, warum es kritisch ist, oder auf der anderen Seite ist es perfekt, und so sollte es aus den Gründen 1 ... 2 ... funktionieren. .

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

V4Vendetta
quelle
0

Vorausgesetzt, der Code ist bereits getestet (und insbesondere freigegeben).

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

Speicher - Es ist sehr unwahrscheinlich, dass das System den Fehler vergisst, was jeder Entwickler tun kann.

Metriken - Die Anzahl der gefundenen und geschlossenen Fehler sowie die benötigte Zeit können einfach zu erfassende Metriken sein, die Aufschluss über den Fortschritt der Codequalität geben

Dringlichkeit - Für den Entwickler scheint es das Wichtigste auf der Welt zu sein, aber die Zeit, die für die Behebung dieses Problems aufgewendet wird, sollte besser für etwas verwendet werden, das der Endbenutzer zuerst möchte (siehe auch Speicher).

Vervielfältigung - Möglicherweise wurde sie bereits entdeckt und wird von einer anderen Person überprüft / behoben. Alternativ ist es vielleicht gegen die Dringlichkeitsregel verstoßen und wurde abgesetzt. Die Tatsache, dass Sie es wiedergefunden haben, bedeutet natürlich nicht nur, dass es nicht getan werden sollte, es könnte auch bedeuten, dass (da es immer weiter auftaucht), dass es jetzt dringender ist, es zu beheben.

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

Umfassende Auswirkungsanalyse - Der billigste Fehler, den Sie finden können, ist der, den Sie kannten, bevor Sie ihn gefunden haben. Anhand dieses Fehlers (insbesondere nach einer Ursachenanalyse) kann schnell klar werden, dass dieses Problem an anderen Stellen im Code auftreten kann. Infolgedessen kann sich das Team entscheiden, es zu suchen, bevor es in einem peinlicheren Moment seinen hässlichen Kopf hebt.

Die Zeit, die für diese (falls vorhanden) aufgewendet wird, hängt weitgehend von der Reife und dem Qualitätsniveau des Codes ab. Die Ursachenanalyse ist für ein winziges Team, das an Demonstrationscode arbeitet, wahrscheinlich übertrieben, aber ein großes Team, das sich mit geschäftskritischer Entwicklung befasst, muss die Lektionen wahrscheinlich effektiv und effizient lernen.

Erfahrungsgemäß gibt es zwei Gründe, warum Entwickler das Tool nicht verwenden:

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

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

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

Gavin H
quelle
0

Ich stimme meistens mit FrustratedWithFormsDesign überein, aber ich denke, es ist noch klarer, wenn das ganze Problem in zwei Bereiche unterteilt ist:

  • Fehlerberichterstattung.
  • Bugfixing.

Diese werden oft als gleich behandelt und ihre Trennung wird mit ziemlicher Sicherheit viel helfen.

Diese können bearbeitet werden mit: Bug Reporting: - Wie jeder sagt, ins System stellen.

Fehlerbehebung: - Alle ein oder zwei Wochen (passen Sie sich an Ihren Entwicklungsplan an, usw.) treffen sich alle am Projekt und entscheiden, was behoben werden soll, von wem usw. Dies war, dass jeder auf derselben Seite ist und sehen kann, was zu tun ist getan werden. In Agile Development ist dies das Sprint Planning Meeting.

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

Junkie
quelle
0

Wenn Sie etwas sehen, dann sagen Sie etwas!

Ich gebe sogar Fehlerberichte zu meinen eigenen Modulen 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.

jqa
quelle
0

Ich denke, dies ist eher eine politische Frage als eine Frage zu bestpractice.

  • Gibt der Bug-Entry jemandem die Schuld?
  • Kann der Kunde Fehlereinträge lesen und sieht, dass zusätzliche Fehler vorliegen. Ist dies ein Reputationsproblem für Ihr Unternehmen?
  • Ist dies wirklich ein Fehler oder eine Funktion, die Sie nicht kennen?
  • Wer wird den Bugfix bezahlen?

Meiner Meinung nach ist es eine gute Praxis, nicht triviale Fehler in das Tracker-System aufzunehmen, aber das Management muss entscheiden, wie es damit umgehen 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 die Fehlerbehebung testen und sicherstellen, dass die Fehlerbehebung keinen neuen Fehler verursacht (Regression)
k3b
quelle