Linee guida per un bug reporting efficace

23 Febbraio 2010
ATTENZIONE! Il post ha più di 2 anni e le informazioni contenute potrebbero essere obsolete (ad esempio a causa di un aggiornamento di versione rispetto agli elementi descritti o links modificati da siti esterni).

Scrivendo un’applicazione è molto probabile (anzi, praticamente sicuro) commettere degli errori di sintassi o logici che durante l’utilizzo del software creano dei bug e ne impediscono il corretto funzionamento. Ciò è valido anche per un software di piccole dimensioni.
Per questo motivo è importante prevedere una fase di testing con relativo bug reporting, anche da far eseguire direttamente all’utente finale che utilizzerà il nostro lavoro. Il test fatto da terzi è fondamentale in quanto è un’operazione “reale” eseguita da qualcuno che non segue lo schema mentale di chi ha sviluppato il codice. Il programmatore infatti, conoscendo cosa c’è “sotto la scocca” del proprio software, tende a tralasciare alcune combinazioni di utilizzo in quanto illogiche (attenzione: per chi scrive codice, non per il cliente finale!).

Per questa fase del lavoro è possibile affidarsi a strumenti di tracking esistenti (come ad esempio Bugzilla) oppure creare uno strumento specifico per le nostre esigenze. Ecco i dati principali da raccogliere per un buon bug reporting:

 

COMPONENTE
In che punto/scheda/url del programma avviene l’errore?

SISTEMA OPERATIVO
Indicare su quale piattaforma è stato notato l’errore e, quando possibile, se il bug si verifica su un singolo sistema operativo o più di uno.

BROWSER - nome e versione
(in caso di applicazioni web based).

VERSIONE DEL SOFTWARE
(se c’è un sistema di versioning visibile all’utente)

TITOLO
Una breve descrizione dell’errore di circa 60-80 caratteri. In questo modo sarà più semplice per gli sviluppatori leggere i report e correggere i bug.

GRAVITA’ DELL’ERRORE
Creare una scala per indicare quanto il bug influisce sul funzionamento del software. Un’icona che esce dall’area di un pulsante non è importante come un crash! Come per il titolo semplifica il lavoro degli sviluppatori in fase di correzione.

DESCRIZIONE
Una descrizione più accurata del bug contenente:

  • il problema spiegato nello specifico
  • i passi per riprodurre l’errore
  • il tipo di errore (c’è un risultato sbagliato o il software smette completamente di funzionare?)

ALLEGATI
In base ai casi potrebbe essere utile allegare un file che manda in crash l’applicazione o uno screenshot per evidenziare meglio un problema.

 

Commenti