Caratteristiche e funzionamento del tool Bugzilla (Defect Tracking System)

Bugzilla

Bugzilla è un “Defect Tracking System” o anche “Bug-Tracking System” web-based client-server sviluppato dalla Bugzilla.org ovvero gli stessi sviluppatori di Mozilla lanciato nel 1998. Il tool è stato sviluppato inizialmente in TLC successivamente si è fatto un porting in Perl in quanto essendo più popolare avrebbe permesso a più sviluppatori di avvicinarsi ad esso e a fornire il loro contributo. Offre il supporto a diversi back-end di database come MySQL, Oracle, PostgreSQL, SQLite. La rapida diffusione di Bugzilla ha richiesto una maggiore semplicità in termini di installazione e interoperabilità con diverse piattaforme e database in modo tale da riuscire ad abilitare e disabilitare funzionalità al momento opportuno e quindi renderlo personalizzabile. L’idea di base su cui è stato concepito lo sviluppo di Bugzilla è quella di realizzare un sistema di bug tracking anche se vi è un trend che cerca di trasformare Bugzilla in un sistema di ticket di supporto tecnico, strumento di gestione delle attività del progetto quindi un vero e proprio sistema di project management. Per quanto riguarda gli utenti che vogliono cercare di estenderne le funzionalità, si dovrebbero seguire in fase di sviluppo alcuni principi di progettazione. Ad esempio Bugzilla deve essere eseguito facilmente su strumenti open source. Il supporto alla integrazione di Bugzilla dovrebbe essere ampliato per supportare i database commerciali, strumenti e sistemi operativi ma non a scapito di quelli open source. Uno dei principali motivi di attrazione verso Bugzilla è la sua attenzione alla leggerezza e velocità. Ridurre al minimo le chiamate al database quando possibile, non prendere più dati del necessario ecc. rendono il prodotto molto snello e particolarmente efficiente.

Anatomia del Bug in Bugzilla

Vengono di seguito elencate le caratteristiche di un bug Bugzilla.

Product e Component. I prodotti hanno la caratteristica di inglobare al loro interno più componenti. Ad esempio bugzilla.mozilla.org’s prodotto “Bugzilla” è formato da diversi componenti (User Intefarce, Administration, E-mail, Documentation, Installation ecc.)
Status e Resolution. Definisce in quale stato si trova o sta attraversando un determinato Bug.
Assign To. La persona, il team a cui il bug è stato assegnato.
QA Contact (opzionale). La persona responsabile per la QA del bug.
URL (opzionale). Possibilità di associare una url al bug.
Summary. Una frase per riassumere il problema.
Status Whiteboard (opzionale a.k.a. Whiteboard). Indica una free-text area in cui scrivere alcune note e tag relativi al bug.
Keywords (opzionale). L’amministratore può definire parole chiave per indicare tag e categorie di bug.
Platform and OS. Indicano il sistema operativo e la piattaforma su cui il bug si è manifestato.
Version. E’ utilizzata qualora vengano rilasciate più release dello stesso prodotto e grazie a questo campo si può collegare il bug alla release in cui si è manifestato e quelle in cui è stato risolto.
Priority. Serve a caratterizzare i bug e a schedularli per la loro risoluzione.
Severity. Serve ad indicare la serietà del problema (va da Blocker a Trivial).
Target (a.k.a. Target Milestone). E’ la versione in cui un determinato bug è stato risolto.
Reporter. Colui che ha riportato/segnalato il bug.
CC list. Una lista di persone a cui vengono inviate le e-mail qualora ci sono dei cambiamenti di un determinato bug.
Time tracking (opzionale). Può essere utilizzato per il monitoraggio del tempo. Al fine di utilizzare questa funzionalità bisogna essere membri del gruppo timetrackingroup. I parametri attraverso i quali è possibile fare il monitoraggio sono: Origin Estimated Time,
Current Estimated Time (calcolato da Hours works a Hours Left), Hours Worked, Hours Left, %Complete, Gain(numero di ore che lo stato di risoluzione del bug mostra in avanti rispetto al Or time), Deadline.
Attachement. Si possono allegare file al bug (come per esempio test-case o patches).
Dependencies (opzionale). Sono delle registrazioni che vengono effettuate qualora il bug non dovesse essere risolto.
Additional Comments. Commenti aggiuntivi per fornire informazioni relative al bug con maggiore livello di dettaglio.
Anche Bugzilla offre la possibilità come altri bug/issues tracker, di personalizzare il ciclo di vita del bug al fine di adattarlo quanto più possibile alle esigenze dell’organizzazione. Viene riportato nella figura seguente un esempio del bugzilla lifecycle.

Ricerca dei bug

Bugzilla offre per la ricerca dei bug una interfaccia (Bugzilla Search Page ) attraverso la quale è possibile ottenere i valori associati a tutti i campi che caratterizzano un bug e che corrispondono ai campi selezionati. Per effettuare ricerche basate su criteri più raffinati si possono utilizzare gli operatori booleani. In questo caso, sono tre campi: Field (la voce che si sta cercando), Operator, Value (il valore con cui il campo deve essere comparato). E’ prevista, anche, una ricerca veloce identificata da un box a piè pagina corredato da una breve descrizione che permette di illustrarne il funzionamento. Le query realizzate in Bugzilla sono case- insensitive e accent-insensitive se si utilizzano database come MySQL e Oracle Database. Se invece usiamo Bugzilla con backend PostgreSQL alcune query sono case-sensitive. Dopo aver lanciato una ricerca viene ritornata una lista di bugs il cui formato è personalizzabile. Alcune delle caratteristiche utili relativi alla lista sono le seguenti: Long Format, XML (per ottenere la bug list in formato xml), CSV (buglist separata da punti, per poter importare in un foglio di calcolo), Feed (per avere informazioni circa i bug che si desidera seguire), I-calendar, Invia e-mail all’assegnatario del bug, Scrivere e Memorizzare i criteri di ricerca. Bugzilla offre inoltre la possibilità di aggiungere/rimuovere tags ai bug per poterne facilitare la gestione. Questi sono peer-user ossia visibili e modificabili solo dagli utenti che gli hanno definiti e possono essere utilizzati nei criteri di ricerca (esempio nella ricerca basic si può scrivere “tag: my_tag_name” ). Questa funzionalità risulta essere particolarmente utile quando si desidera tenere traccia di diversi bug perché invece di “mescolare ” tutte le modalità è possibile memorizzare i bug in liste separate create in base alle ragioni per cui si monitorano. Bugzilla prevede la possibilità di clonare un bug operazione per poterne osservare il comportamento in uno scenario differente.