Home > varie > Linee guida per un bug reporting efficace

Linee guida per un bug reporting efficace

23 febbraio 2010 No Comments

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.

Tags: articoli

Lascia un Commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

*

È possibile utilizzare questi tag ed attributi XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>