Einschätzung eines unzuverlässigen Tests
Wie man einen unzuverlässigen Test einschätzt: Warum es zwei Schätzungen sind und nicht nur eine, und warum eine zeitliche Begrenzung besser ist als ein Streit über Punkte, wenn die Antwort davon abhängt, was man herausfindet.
Ein unzuverlässiger Test besteht aus zwei Schätzwerten. Sie wissen noch nicht, welcher davon der richtige ist.
In einem Fall handelt es sich um eine einzeilige Korrektur: eine Annahme bezüglich des Zeitablaufs, eine Abhängigkeit von der Testreihenfolge, ein fehlendes await. Im anderen Fall handelt es sich um eine Race Condition im Produktionscode, die erst nach drei Tagen entdeckt wurde und zufällig durch den Test aufgedeckt wurde. Wenn die Karten von 2 bis 13 verteilt sind, ist sich das Team nicht über den Umfang uneinig. Es ist sich uneinig darüber, um welche Art von Fehler es sich handelt – und genau das ist die eigentliche Unbekannte.
Eine Schätzung, um herauszufinden, wie groß etwas ist, anstatt erst im Nachhinein – genau das führt dazu, dass diese Geschichte in Woche eins bei 5 und in Woche drei bei 13 landet. Die Lösung liegt nicht in einer genaueren Zahl, sondern in einer anderen Herangehensweise an die Arbeit. Legen Sie für die Untersuchung einen festen Zeitrahmen fest und schätzen Sie dann den tatsächlichen Aufwand, sobald der Umfang bekannt ist.
Was in dem Raum gesagt wird
Ingenieur A: „Wenn es aus dem von mir vermuteten Grund unzuverlässig ist, ist das eine 2.“
Ingenieur B: „Wenn es aus dem Grund, den ich vermute, unzuverlässig ist, dann ist es eine 13.“
Leitfrage: „Hat jemand das Programm tatsächlich lokal mit festgelegter Startzahl ausgeführt?“
QA: „Es schlägt nur in der CI fehl. Auf einem Entwicklungsrechner kommt es nie vor.“
Fragen, die man sich vor der Stimmabgabe stellen sollte
- Tritt das Problem lokal auf oder nur in der CI?
- Wie oft tritt der Fehler auf: bei jedem 50. Versuch, bei jedem 5. Versuch, bei jedem zweiten Versuch?
- Seit wann tritt der Fehler auf? Bei welchem Commit?
- Ist der Test fehlerhaft, oder deckt er tatsächlich etwas auf?
- Deaktiviert es in der Zwischenzeit jemand, und mit welchen Kosten ist dies verbunden?
Die Diskrepanz zwischen Ingenieur A und Ingenieur B ist keine Meinungsverschiedenheit hinsichtlich der Story-Points, die sich durch einen Durchschnitt ausgleichen lässt. Es handelt sich um eine Unbekannte, die es zu klären gilt. Ein kurzer, begrenzter Spike gleicht sie aus; ein heftigerer Streit hingegen nicht.
Legen Sie einen Zeitrahmen fest, keine feste Lösung. Einen halben Tag für die Untersuchung, dann einen richtigen Artikel über das, was Sie dabei herausfinden.
Lesen Sie „Schätzung eines Fehlers ohne Reproduktion“ für denselben Fall und „Häufige Fehler beim Planning Poker“ zur Schätzung von Fehlern auf Feature-Ebene. Sehen Sie sich die anderen Beispiele für durchgeführte Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald die Untersuchung zu einem Ergebnis geführt hat.