Wir verwenden verschiedene Formalismen in Titeln / Themen für verschiedene Zwecke (Story, Feature, Test), aber wir haben keine Formalismen für Fehlerberichte ...
Wir untersuchen die Vorteile eines standardisierten Titelformats auf Bugs .
Wir verwenden diese Formalismen mit ziemlichem Erfolg in Titeln /* Fächern * .
Für Scrum-Geschichten verwenden wir den folgenden Titelformalismus:
As a <role>, I want <goal/desire> so that <benefit>
Für FDD-Funktionen (Feature-Driven Development) verwenden wir den folgenden Titelformalismus:
<action> the <result> <by|for|of|to> a(n) <object>
Für Akzeptanztests (Verhalten) verwenden wir den folgenden Formalismus:
GIVEN THAT <conditions>/<initial state>/<context> (no action)
WHEN <actions> (performed by user)
THEN <expected results>/<consequences> (that the system does)
Für Fehlerberichte denken wir, dass wir einen Titelformalismus annehmen werden, der dem folgenden nahe kommt:
I was <context>, I did <action>, I got <actual behaviour>
Ich konzentriere mich hier nur auf den Titel, nicht auf die vollständige Beschreibung!
Vorteile:
Nachteile:
Dieser Formalismus reicht jedoch nicht nur für einen Titel aus, da möglicherweise einige Richtlinien erforderlich sind:
Dies ist natürlich nicht das Ziel dieses Beitrags, aber in der vollständigen Beschreibung des Fehlerfreitextes wird Folgendes stehen:
Mit allen Feldern der Bugtracker-Software, wie betroffene/fixierte Versionen, Schweregrad, Priorität, Links zu anderen Tickets usw.
Aber das ist nicht Thema dieses Beitrags...
Kommen wir zurück zu den Fehlertiteln / * Themen *.
Halten Sie es für sinnvoll, einen solchen Titelformalismus einzuführen?
Nein. Ein Titel ist selten ein eindeutiger Identifikator über Fehler hinweg, noch wird er wahrscheinlich alleine genug kommunizieren, um die Einschränkungen zu rechtfertigen.
Obwohl ich zustimme, dass Titel aussagekräftig sein sollten, ist es sehr schwierig, einen kurzen Formalismus zu erstellen, der in ein paar Dutzend Zeichen zusammengefasst werden könnte. Sie schlagen zum Beispiel vor:
I was <context>, I did <action>, I got <actual behaviour>
Das ist schon ziemlich lang, aber wenn Sie dieser Idee bis zu ihrem logischen Ende folgen, sollte es noch länger werden. Ein Teil eines guten Fehlermeldeprozesses besteht darin, festzustellen, wie der Fehler oder die Fehlfunktion die Erwartungen (manchmal auch als Benutzervertrag bezeichnet) nicht erfüllt hat, sodass das erwartete Verhalten fehlt. Wenn ich dasselbe Beispiel verwende, könnte ich sagen:
Ich habe versucht, eine Nachricht
mit dem--clearsignFlag eindeutig zu signieren, aber
als ich die Nachricht signiert habe, habe ich eine Kopfzeile und meinen ursprünglichen Text zurückerhalten.
Ich habe erwartet, dass dem Header und dem Text ein gültiger Signaturblock folgt.
Der Teil, in dem ich erkläre, was ich erwartet habe, ist wesentlich für das Verständnis des Problems. Bedenken Sie: Wenn ich F1 drücke und mein Teamkollege einen Stromschlag bekommt, was genau ist der Fehler? Ist das Problem, dass dies nur passieren sollte, wenn ich F2 drücke? Dass der Stromschlag ein Pie ins Gesicht hätte sein sollen? Oder ist dies tatsächlich eine Funktion, die wie vorgesehen funktioniert?
Fürs Protokoll, ich habe tatsächlich einen echten Fehlerbericht eingereicht – lose basierend auf dem Beispiel, das ich oben gegeben habe, aber der eigentliche Titel war „GPG-Dienste signieren nicht ordnungsgemäß mit Smartcards“. Dieser Titel ergibt für Sie ohne Kontext vielleicht keinen Sinn, war aber tatsächlich eine genaue Zusammenfassung des Fehlers und dauerte nur 46 Zeichen. Die Verwendung Ihres Formalismus hätte 139 Zeichen erfordert und (meiner Meinung nach) das Problem nicht annähernd so gut zusammengefasst.
Das eigentliche zugrunde liegende Problem ist, warum Sie denken, dass Sie Fehlertitel überhaupt einschränken müssen. Dies ist oft ein Projektgeruch, der auf Folgendes hinweist:
Es ist zwar nichts falsch daran, Ihren Fehlerberichtsprozess zu formalisieren, aber denken Sie daran, dass Prozesskontrollen ein definiertes Problem oder Risiko effektiv kontrollieren sollten. In Ihrem Fall ist unklar, was Sie kontrollieren und ob die vorgeschlagene Kontrolle Ihr Risiko tatsächlich mindern wird.
Dies ist etwas, das Sie vielleicht mit Ihrem Team und Ihren Stakeholdern besprechen möchten. Wenn es sich um ein echtes Problem handelt, ist es in der Regel immer noch besser, eine Basislösung einzusetzen, die von den Kontrollverantwortlichen unterstützt wird, anstatt einen Prozess per Befehl aufzuerlegen. YMMV.
Nun, wenn solch ein Formalismus für Sie funktioniert – dann möchte ich nichts dagegen sagen.
Wenn der Fehler tatsächlich übersehen und nicht als Anforderung besprochen wird – dann werde ich den Kontext setzen und ihn als Anforderung schreiben und das tatsächliche Ergebnis angeben. Ich verwende Gurken gerne für solche Zwecke:
Angenommen, ich bin ein Benutzer, der die Parksteuer berechnen möchte,
und ich habe das Startdatum auf den 1. Februar 2012 festgelegt,
und das Enddatum ist den 29. Februar 2012
, und die aktuelle Steuer pro Tag beträgt 1 USD
, wenn ich die Steuer für den Zeitraum berechne
Dann sollte ich ein Ergebnis von 29 Dollar erhalten
, aber das tatsächliche Ergebnis war 28 Dollar
Dann kann ich einen Titel vergeben. Der Titel enthält den tatsächlichen Bestandteil (Steuerrechner) und die Frage oder Behauptung:
Steuerrechner sollte Schaltjahre berücksichtigen
oder
Steuerrechner berechnet falsche Summe für Schaltjahre
Andererseits würde ich nicht viel Kontext setzen, wenn ich möchte beschreiben Serverabstürze oder JavaScript-Fehler. Es wäre lächerlich, solche Dinge in Given When Then zu beschreiben oder einen geschäftlichen Kontext für JavaScript-Fehler zu setzen. Das ist ein technischer Fehler und er sollte einen technischen Titel haben (z. B. eine Beschreibung der Fehlermeldung)
. Einige meiner Fehler sind so kompliziert zu beschreiben und zu reproduzieren, dass ich besser eine Videoaufzeichnung anhänge.
Ich schreibe Bugs für Entwickler und Management. Mein Ziel ist es, Fehlerberichte zu erstellen, die klar und kurz sind. Unter Berücksichtigung des agilen Kontexts, in dem ich arbeite, können wir alle verpassten Details jederzeit per Skype von face 2 face besprechen.
Also würde ich Bugs auf so formelle Weise schreiben. Aber jedes Projekt hat seinen eigenen Kontext. Und es kann für Sie funktionieren, wenn ein solcher Ansatz Probleme löst.
Sie können nur feststellen, ob etwas ein Fehler ist, wenn es nicht wie ursprünglich beabsichtigt funktioniert, d. h. die ursprünglichen Akzeptanzkriterien nicht mehr erfüllt werden. Protokollieren Sie einfach den Fehler mit den fehlgeschlagenen Akzeptanzkriterien.
Wenn Sie die Akzeptanzkriterien überhaupt nicht hatten, dann haben Sie entweder eine Menge technischer Schulden zurückzuzahlen, und dies sollte als technische Schuld angesehen und für das Management sichtbar gemacht werden.
Wenn es schließlich ein neues Akzeptanzkriterium ist, das als Fehler wahrgenommen wird, behandeln Sie es als Änderung und fügen Sie es dem Product Backlog hinzu.
Eine der neuen Möglichkeiten in einer Cloud-Software, die ich gehört habe, ist die folgende Art des Testens und Meldens von Fehlern. Dies ist ein Offshore- und Onsite-Modell, bei dem die Überrundung 2 bis 3 Stunden beträgt.
Auf diese Weise wird viel Zeit gespart und das Problem ist klar definiert. Der Gedanke, dies zu teilen, ist möglicherweise keine genaue Antwort auf den Formalismus. Dies ist auch eine Möglichkeit, wie wir es tun können.
Willl