www.fabiobeta.it

« Customer on Site: not enough
Passaggio di consegne: corto è meglio! »

Bug Hunting
5 Giugno 2007

Negli ultimi anni ho avuto la "fortuna" di fare spesso il cacciatore di bachi. Da una chiacchierata con un amico è saltato fuori l'elenco degli step che mi sono reso conto di seguire, inframmezzati da qualche "trucco". Visto che mi sembra sia utile che divertente, ecco come io consiglio di approcciare la caccia al bug:

1. Verifica prima dove l'utente ha visto il baco. Può essere che semplicemente qualcosa non gli sia chiaro e non vuoi passare mezza giornata a cercare un fantasma. Se riesci, verifica con l'utente: da più indizi da cui partire.

2. Verifica nel punto più profondo dell'applicazione se ci sono problemi (per esempio, se il baco è un dato visualizzato scorrettamente su una pagina di un sito, potresti verificare se sul database c'è). Non vale la pena di diventare pazzi a capire perché non si vede il nome dell'utente, se l'applicazione non sa il nome dell'utente.

3. A questo punto, se ancora non hai trovato la causa del problema, scrivi un test per riprodurlo! Nulla fa perdere più tempo che dover scorrere 5 pagine di un sito e digitare 2 password ogni volta che vuoi fare una prova. Mettiti nella condizione in cui, in 2 microsecondi, sei in grado di verificare se hai risolto il bug, o anche solo di osservare come varia il comportamento del sistema al variare di condizioni al contorno.

4. A questo punto... stringi il cerchio. Il fetente è nascosto da qualche parte lì in mezzo. Mescola istinto (magari hai già scovato bachi simili e sai dove si annidano) e metodicità. Non dare per scontato nulla. Se non hai punti di partenza, parti dalle radici e risali tutti i passi fino al punto in cui si manifesta il baco (non so perchè, ma di solito partire dal fondo è più rapido che partire dalla cima)

5. Se ti sembra che il problema dipenda da un baco del linguaggio di programmazione... fermati, fai due passi e riguarda il problema escludendo questa possibilità.E' veramente improbabile, e lo sai. Come insegnano i PragmaticProgrammers, "select Isn't Broken".

6. Non bloccarti: Se capita, chiama un collega a dare un occhio. Se il collega non ha tempo di alzarsi, vai dai lui e raccontagli il problema, il semplice fatto di doverlo mettere in parole potrebbe farti venire un'illuminazione. Se non hai un collega a cui parlare, raccontalo al mouse, un teddy bear, una papera di gomma o a Obi-Wan Kenoby, ma fallo. Fa miracoli.

7. Se c'è fretta, sdoppia l'indagine. In mia esperienza il bug hunting è un'attività poco adatta al PairProgramming: ognuno ha uno stile personale di indagine. E' più efficace lo SwarmProgramming: facendo agire in modo parallelo e indipendente più persone aumenti la probabilità che una arrivi prima all'obiettivo.

8. Stringi il cerchio finché trovi il maledetto.

9. Una volta trovato, fissa il problema alla radice, non piegarti ad esso. E' facile correggere o "gestire" un errore vicino al punto in cui ti da problemi, ma se non vai alla fonte, fai (almeno) due errori: lasci aperta la possibilità che altrove si riscontri lo stesso problema e dai una responsabilità ad un pezzo di codice che non dovrebbe averla.

10. Fai un buon lavoro: se hai trovato un errore, fai mente locale se ci possono essere problemi simili in altri punti dell'applicazione. Fa veramente male al rapporto con l'utente fargli scoprire lo stesso baco in tre momenti diversi.

11. Fatto tutto questo, verifica manualmente la soluzione del problema. C'è il rischio che tu abbia introdotto altre anomalie, che i test di controllo non evidenziano. In questa fase, dopo una caccia al baco estenuante, è facile cedere al lato oscuro e lasciare all'utente la verifica ("Tanto se non funziona mi richiama")... ma è sbagliato: abitua l'utente a ricevere software funzionante, e migliorerai la fiducia che ripone in te.

send a feedback to fabio

« Customer on Site: not enough
Passaggio di consegne: corto è meglio! »