Schä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 ein Zeitrahmen besser ist als eine Diskussion über Punkte, wenn die Antwort davon abhängt, was Sie herausfinden.
Ein unzuverlässiger Test besteht aus zwei Schätzungen. Sie wissen noch nicht, welche davon zutrifft.
In einem Fall handelt es sich um eine Korrektur in einer einzigen Zeile: eine Annahme bezüglich des Zeitablaufs, eine Abhängigkeit von der Testreihenfolge, ein fehlendes await. Im anderen Fall wurde nach drei Tagen eine Race Condition im Produktionscode entdeckt, die der Test zufällig aufgedeckt hat. 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, was die eigentliche Unbekannte ist.
Eine Schätzung, um herauszufinden, wie groß etwas ist – und nicht erst im Nachhinein –, ist der Grund dafür, 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, 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. Mal, bei jedem 5. Mal oder bei jedem zweiten Durchlauf?
- Wann sind die Probleme aufgetreten? Bei welchem Commit?
- Ist der Test fehlerhaft, oder weist er tatsächlich auf etwas Reales hin?
- 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 Mittelwertbildung ausgleichen lässt – es handelt sich um eine Unbekannte, die es zu untersuchen gilt. Ein kurzer, begrenzter Spike gleicht sie aus; eine heftigere Auseinandersetzung 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 Reproduktionsmöglichkeit“ 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.