Valutazione di un test instabile
Come stimare un test instabile: perché occorrono due stime, anziché una sola, e perché fissare un limite di tempo è preferibile a discutere sui punti quando la risposta dipende da ciò che si riscontra.
Un test inaffidabile consiste in due stime. Non si sa ancora quale delle due sia quella corretta.
awaitUna versione consiste in una correzione di una sola riga: un’ipotesi relativa alla temporizzazione, una dipendenza dall’ordine dei test, un elemento mancante. L’altra versione richiede tre giorni di analisi approfondita di una condizione di competizione nel codice di produzione che il test è riuscito a individuare per caso. Quando le schede vanno da 2 a 13, il team non è in disaccordo sulla dimensione, ma su che tipo di bug si tratti, che è l’effettiva incognita.
Fare una stima per capire quanto sia grande un problema, anziché farlo a posteriori, è il motivo per cui questa storia si è conclusa con un punteggio di 5 nella prima settimana e di 13 nella terza. La soluzione non sta in un dato più preciso, ma in un approccio diverso al lavoro. Definite un intervallo di tempo per l’analisi, quindi valutate la soluzione effettiva una volta che ne avrete compreso l’entità.
Ciò che viene detto nella stanza
Ingegnere A: «Se il problema è dovuto al motivo che immagino, questo è un 2.»
Ingegnere B: «Se il problema è dovuto al motivo che io ritengo, è un 13.»
Introduzione: “Qualcuno l’ha mai effettivamente eseguito in locale con il seed fissato?”
QA: «Il test fallisce solo nella CI. Mai su una macchina di sviluppo.»
Domande che vale la pena porsi prima di votare
- Il problema si verifica anche in ambiente locale o solo nell’ambiente di integrazione continua (CI)?
- Con quale frequenza si verifica un errore: 1 volta su 50, 1 volta su 5, una volta su due?
- Quando ha iniziato a non funzionare correttamente? Quale commit?
- Il test è errato, oppure sta rilevando qualcosa di reale?
- C’è qualcuno che nel frattempo lo sta disattivando, e a quale costo?
Il divario tra l’ingegnere A e l’ingegnere B non è una divergenza sui story-points che si possa appianare calcolando una media: è un’incognita da approfondire. Uno spike breve e ben definito lo colma; una discussione più accesa, invece, no.
Stabilite un intervallo di tempo, non una soluzione definitiva. Mezza giornata per indagare, poi un articolo vero e proprio su qualunque cosa scopriate.
Si veda la stima di un bug senza riproducibilità per un caso analogo, e gli errori comuni nel Planning Poker per la stima dei bug a livello di funzionalità. Si consultino gli altri esempi di stime già elaborati, oppure si avvii una sessione gratuita di Planning Poker una volta ottenuto il risultato dell’analisi.