Alkampfer's Place

Il blog di Gian Maria Ricci
posts - 659, comments - 871, trackbacks - 80

My Links

News

Gian Maria Ricci Mvp Logo CCSVI in Multiple Sclerosis

English Blog

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

I miei siti

Siti utili

I bug debbono essere granulari

Uno dei problemi maggiori che trovo talvolta nelle segnalazioni di bug è quello di segnalare troppo in un unico bug. Ad esempio si parte con un bug che dice

Nella vista XYZ ho provato a fare  A poi B poi C ed è chrashato.

Si procede quindi a correggere quel bug e metterlo come “risolto”, ma poi il bug viene riaperto con una nota aggiunta:

Ok ora non crasha più, però quando faccio C mi aspetto che succeda K invece accade U

Questo deve essere a mio avviso un nuovo bug, perché purtroppo io vedo ancora nel titolo e nella descrizione “Nella vista XYZ ho provato a fare A poi B poi C ed è crashato”, ma in realtà la nota ora mi riporta un errore differente. Si procede quindi a correggere il bug nuovo che è nella nota, si mette il bug come “resolved”, ma il bug viene riaperto con una nota che dice

Ok adeso funziona tutto, ma nella colonna di mezzo modificherei XYZ, bla bla bla bla bla bla, e frasi del tipo, per XYZ forse bisognerebbe attuare una procedura che… [15 righe di testo con change request sulle specifiche che riguardano la procedura che aveva il bug]

Insomma, quello non è più un bug, è diventato una accozzaglia di robaccia che non fa altro che complicare il progetto. Un bug deve essere coinciso e granulare, non si deve mai cambiarne il significato con le note e soprattutto non ha senso riaprire un bug mettendo una nota “ora funziona tutto, ma modificherei la procedura XYZ in modo che faccia … ”, questa è la morte dell’ALM.

Quindi mettiamo alcune regole per i nostri cari tester o per chiunque si accinga a gestire un bug.

1) Verifica che il bug non sia già stato segnalato
2) Scrivi un titolo coinciso, e se possibile nel titolo o con qualsiasi altro campo a disposizione indica chiaramente in che punto si verifica il bug
3) Inserisci una descrizione ed i passi per replicare il bug.
4) quando il bug viene “risolto”, riesegui i passi e verifica che non si presenti più e poi chiudilo.
5) Se qualche altra cosa non funziona apri un nuovo bug (non mettere note nel vecchio perchè è più veloce)
6) Non si possono cambiare requisiti aggiungendo note ad un bug :)

Le note servono solamente ad aggiungere chiarezza al bug, non ad inserire nuovi bug o nuove specifiche. :)

Gian Maria.

Print | posted on mercoledì 21 settembre 2011 16:32 |

Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET