Valutazione di un bug senza possibilità di riproduzione
Come valutare un bug per il quale non è possibile riprodurre il problema: non è possibile quantificare la portata della correzione, ma solo quella della ricerca. Come stabilire un limite di tempo per l’indagine anziché votare su una story che nessuno può vedere.
Se non riuscite a riprodurlo, non potete stimarlo. Potete stimarlo cercandolo.
Un bug non riproducibile è costituito da due incognite racchiuse in un unico ticket. La prima incognita è la causa: si osserva un sintomo in produzione, ma non esiste un modo affidabile per riprodurlo localmente, né una traccia dello stack coerente, né una riga nei log che lo preceda sistematicamente. La seconda incognita è la correzione, che dipende interamente dalla prima. Assegnare un punteggio alla correzione prima che se ne conosca la causa equivale a valutare una storia che il team non può effettivamente vedere.
Una volta individuata la causa, la soluzione non è sempre difficile; spesso basta modificare una sola riga di codice. La parte più onerosa è proprio l’individuazione del problema. Stimare il tempo necessario per la ricerca è realistico; stimare quello necessario per la correzione è invece un pio desiderio.
Ciò che viene detto nella sala
Ingegnere A: «Credo che si tratti dell’invalidazione della cache.»
Ingegnere B: «Credo che sia una questione di attitudine del lavoratore.»
Introduzione: “Qualcuno è riuscito a realizzarlo su richiesta?”
Domanda: «Abbiamo provato venti soluzioni diverse. Nessuna si è rivelata affidabile.»
Assistenza: «Si tratta di tre utenti alla settimana, sempre il martedì pomeriggio.»
Domande da porsi prima di votare
- Qual è il sintomo e con quale frequenza si manifesta?
- Abbiamo già attivato la registrazione sui percorsi sospetti, oppure dobbiamo prima aggiungerla?
- Esiste un cliente con un account notoriamente difettoso su cui possiamo riprodurre il problema?
- Qual è il costo settimanale del bug per il cliente e tale costo giustifica un’analisi approfondita?
- Qual è il termine previsto per l’indagine prima di riesaminare la questione?
Due teorie ben definite e nessuna riproducibilità non sono un dato su cui basarsi; si tratta piuttosto di una ricerca da finanziare. Assegnatele un budget e fissate una scadenza, quindi rivalutate la situazione una volta che la causa avrà un nome.
Stabilisca un budget per la ricerca. Una volta individuata la causa, valuti autonomamente la soluzione necessaria.
Si veda Come stimare un test inaffidabile per lo stesso caso e Errori comuni nel Planning Poker sulla stima dei bug con precisione a livello di funzionalità. Si consultino gli altri esempi di stime già elaborati, oppure si avvii una sessione gratuita di Planning Poker quando la causa è nota.