Perché un buon Bug Report?

Se il tuo Bug report è efficace, allora le sue possibilità di essere risolto sono più alte. Quindi la correzione di un bug dipende da quanto efficacemente lo si segnala. Segnalare un bug non è altro che un’abilità e vi spiegherò come raggiungere questa abilità.

“Lo scopo di scrivere un rapporto sui problemi (bug report) è quello di far risolvere i bug” – Da Cem Kaner. Se un tester non segnala correttamente un bug, il programmatore molto probabilmente rifiuterà questo bug dichiarandolo irriproducibile.

Questo può ferire il morale del tester e a volte anche il suo ego. (Suggerisco di non mantenere alcun tipo di ego. L’ego come “Ho segnalato il bug correttamente”, “Posso riprodurlo”, “Perché lui/lei ha rifiutato il bug?”, “Non è colpa mia” ecc,).

Quali sono le qualità di un buon Bug Report di un software?

Tutti possono scrivere un Bug report. Ma non tutti possono scrivere un Bug report efficace.

Dovresti essere in grado di distinguere tra un bug report medio e un buon bug report. Come distinguere tra un buon Bug Report e uno cattivo? È molto semplice, applicare le seguenti caratteristiche e tecniche per segnalare un bug.

Caratteristiche e tecniche includono

#1) Avere un numero di bug chiaramente specificato: Assegnare sempre un numero unico ad ogni segnalazione di bug. Questo, a sua volta, vi aiuterà a identificare il record del bug. Se state usando uno strumento automatico di segnalazione di bug, questo numero unico sarà generato automaticamente ogni volta che segnalate il bug.

Annotate il numero e una breve descrizione di ogni bug che avete segnalato.

#2) Riproducibile: Se il tuo bug non è riproducibile, allora non verrà mai risolto.

Dovresti menzionare chiaramente i passi per riprodurre il bug. Non supporre o saltare alcun passo di riproduzione. Un bug che è descritto passo dopo passo è facile da riprodurre e risolvere.

#3) Sii specifico: Non scrivere un saggio sul problema.

Siiii specifico e al punto. Cerca di riassumere il problema con un minimo di parole ma in modo efficace. Non combinare più problemi anche se sembrano simili. Scrivete rapporti diversi per ogni problema.

Effective Bug Reporting

Il bug reporting è un aspetto importante del Software Testing. Un Bug report efficace comunica bene con il team di sviluppo ed evita confusione o cattiva comunicazione.

Un buon Bug report dovrebbe essere chiaro e conciso senza nessun punto chiave mancante. Qualsiasi mancanza di chiarezza porta a malintesi e rallenta anche il processo di sviluppo. La scrittura e la segnalazione dei difetti è una delle aree più importanti ma trascurate nel ciclo di vita del test.

Una buona scrittura è molto importante per archiviare un bug. Il punto più importante che un tester dovrebbe tenere a mente è di non usare un tono autoritario nel rapporto. Questo rompe il morale e crea un rapporto di lavoro malsano. Usate un tono suggestivo.

Non date per scontato che lo sviluppatore abbia fatto un errore e quindi potete usare parole dure. Prima di segnalare, è altrettanto importante controllare se lo stesso bug è stato segnalato o no.

Un bug duplicato è un peso nel ciclo di test. Controllate l’intera lista dei bug conosciuti. A volte, gli sviluppatori potrebbero aver conosciuto il problema e averlo ignorato per un futuro rilascio. Si possono anche usare strumenti come Bugzilla che cerca automaticamente i bug duplicati. Tuttavia, è meglio cercare manualmente qualsiasi bug duplicato.

Le informazioni di importazione che un rapporto di bug deve comunicare sono “Come?” e “Dove?” Il rapporto dovrebbe rispondere chiaramente come è stato eseguito il test e dove si è verificato esattamente il difetto. Il lettore dovrebbe riprodurre facilmente il bug e trovare dove si trova il bug.

Tenete a mente che l’obiettivo di scrivere il rapporto di bug è di permettere allo sviluppatore di visualizzare il problema. Lui/lei dovrebbe capire chiaramente il difetto dal rapporto di bug. Ricordatevi di dare tutte le informazioni rilevanti che lo sviluppatore sta cercando.

Inoltre, tenete a mente che un rapporto di bug sarebbe conservato per un uso futuro e dovrebbe essere ben scritto con le informazioni richieste. Usate frasi significative e parole semplici per descrivere i vostri bug. Non usare affermazioni confuse che fanno perdere tempo al revisore.

Riporta ogni bug come un problema separato. In caso di problemi multipli in un singolo rapporto di bug, non puoi chiuderlo a meno che tutti i problemi non siano risolti.

Pertanto è meglio dividere i problemi in bug separati. Questo assicura che ogni bug possa essere gestito separatamente. Un rapporto di bug ben scritto aiuta uno sviluppatore a riprodurre il bug sul proprio terminale. Questo li aiuta anche a diagnosticare il problema.

Come segnalare un bug?

Utilizza il seguente semplice modello di rapporto bug:

Questo è un semplice formato di rapporto bug. Può variare a seconda dello strumento di segnalazione di bug che stai usando. Se stai scrivendo un rapporto di bug manualmente allora alcuni campi devono essere menzionati specificamente come il numero di bug, che dovrebbe essere assegnato manualmente.

Reporter: il tuo nome e indirizzo email.

Prodotto: In quale prodotto hai trovato questo bug.

Versione: La versione del prodotto, se presente.

Componente: Questi sono i principali sottomoduli del prodotto.

Piattaforma: Menziona la piattaforma hardware dove hai trovato questo bug. Le varie piattaforme come ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ ecc.

Sistema operativo: Menziona tutti i sistemi operativi dove hai trovato il bug. Sistemi operativi come Windows, Linux, Unix, SunOS, Mac OS. Menziona anche le diverse versioni del sistema operativo come Windows NT, Windows 2000, Windows XP ecc, se applicabile.

Priorità: Quando dovrebbe essere risolto un bug? La priorità è generalmente impostata da P1 a P5. P1 come “risolvere il bug con la massima priorità” e P5 come “risolvere quando il tempo lo permette”.

Severità: Questo descrive l’impatto del bug.
Tipi di gravità:

• Bloccante: Nessun ulteriore lavoro di test può essere fatto.
• Critico: Blocco dell’applicazione, perdita di dati.
• Maggiore: Maggiore perdita di funzione.
• Minore: Minore perdita di funzione.
• Banale: Alcuni miglioramenti dell’interfaccia utente.
• Miglioramento: Richiesta di una nuova funzione o qualche miglioramento in quella esistente.

Status: Quando stai registrando il bug in qualsiasi sistema di tracciamento dei bug, allora per default lo stato del bug sarà ‘New’.
In seguito, il bug passa attraverso varie fasi come Fixed, Verified, Reopen, Won’t Fix, etc.

=> Clicca qui per leggere di più sul dettagliato Bug Life Cycle.

Assign To: Se sai quale sviluppatore è responsabile di quel particolare modulo in cui si è verificato il bug, allora puoi specificare l’indirizzo email di quello sviluppatore. Altrimenti tienilo vuoto perché questo assegnerà il bug al proprietario del modulo, altrimenti il manager assegnerà il bug allo sviluppatore. Possibilmente aggiungi l’indirizzo email del manager nella lista CC.

URL: L’URL della pagina in cui si è verificato il bug.

Sommario: Un breve riassunto del bug per lo più in 60 parole o meno. Assicurati che il tuo riassunto rifletta su qual è il problema e dove si trova.

Descrizione: Una descrizione dettagliata del bug.

Utilizzare i seguenti campi per il campo descrizione:

• Produrre i passi: Chiaramente, menzionare i passi per riprodurre il bug.
• Risultato atteso: Come dovrebbe comportarsi l’applicazione sui passi sopra menzionati.
• Risultato effettivo: Qual è il risultato effettivo dell’esecuzione dei passi di cui sopra, cioè il comportamento del bug.

Questi sono i passi importanti nella segnalazione del bug. Puoi anche aggiungere il “Tipo di rapporto” come un altro campo che descriverà il tipo di bug.

I tipi di rapporto includono:

1) Errore di codifica
2) Errore di progettazione
3) Nuovo suggerimento
4) Problema di documentazione
5) Problema hardware

Funzioni importanti nel tuo rapporto di bug

Di seguito sono indicate le caratteristiche importanti nel rapporto di bug:

#1) Numero/id del bug

Un numero di bug o un numero di identificazione (come swb001) rende molto più facile la segnalazione di un bug e il riferimento ad esso. Lo sviluppatore può facilmente controllare se un particolare bug è stato risolto o no. Rende l’intero processo di test e retesting più fluido e facile.

#2) Titolo del bug

Il titolo del bug viene letto più spesso di qualsiasi altra parte della segnalazione. Dovrebbe dire tutto su ciò che è contenuto nel bug.

Il titolo del bug dovrebbe essere abbastanza suggestivo che il lettore possa capirlo. Un titolo chiaro rende il bug facile da capire e il lettore può sapere se il bug è stato segnalato prima o è stato risolto.

#3) Priorità

In base alla gravità del bug, può essere impostata una priorità per esso. Un bug può essere un bloccante, critico, maggiore, minore, banale o un suggerimento. Si può dare una priorità ai bug da P1 a P5 in modo che quelli importanti siano visti per primi.

#4) Piattaforma/Ambiente

La configurazione del sistema operativo e del browser è necessaria per una chiara segnalazione di bug. È il modo migliore per comunicare come il bug può essere riprodotto.

Senza l’esatta piattaforma o ambiente, l’applicazione può comportarsi in modo diverso e il bug dalla parte del tester potrebbe non essere replicato dalla parte dello sviluppatore. Quindi è meglio menzionare chiaramente l’ambiente in cui il bug è stato rilevato.

#5) Descrizione

La descrizione del bug aiuta lo sviluppatore a capire il bug. Descrive il problema riscontrato. Una cattiva descrizione creerà confusione e farà perdere tempo agli sviluppatori e anche ai tester.

È necessario comunicare chiaramente l’effetto della descrizione. È sempre utile usare frasi complete. È una buona pratica descrivere ogni problema separatamente invece di sminuzzarli tutti insieme. Non usare termini come “penso” o “credo”.

#6) Passi da riprodurre

Un buon Bug report dovrebbe menzionare chiaramente i passi da riprodurre. I passi dovrebbero includere le azioni che causano il bug. Non fare dichiarazioni generiche. Siate specifici nei passi da seguire.

Un buon esempio di procedura ben scritta è dato qui sotto

Passi:

• Selezionare il prodotto Abc01.
• Cliccare su Aggiungi al carrello.
• Clicca su Rimuovi per rimuovere il prodotto dal carrello.

#7) Risultato atteso e reale

La descrizione di un bug è incompleta senza i risultati attesi e reali. È necessario delineare qual è il risultato del test e cosa dovrebbe aspettarsi l’utente. Il lettore dovrebbe sapere qual è il risultato corretto del test. Chiaramente, menzionate cosa è successo durante il test e qual è stato il risultato.

#8) Screenshot

Un’immagine vale più di mille parole. Fate uno Screenshot dell’istanza di fallimento con didascalie appropriate per evidenziare il difetto. Evidenziate i messaggi di errore inattesi con un colore rosso chiaro. Questo attira l’attenzione sull’area richiesta.

Alcuni suggerimenti aggiuntivi per scrivere un buon bug report

Di seguito sono riportati alcuni suggerimenti aggiuntivi per scrivere un buon bug report:

#1) Segnala il problema immediatamente

Se trovi un bug durante i test, allora non devi aspettare di scrivere un bug report dettagliato più tardi. Invece, scrivi il rapporto sul bug immediatamente. Questo assicurerà una buona e riproducibile segnalazione di bug. Se decidi di scrivere il rapporto sul bug più tardi, allora ci sono alte possibilità di perdere i passi importanti nel tuo rapporto.

#2) Riproduci il bug tre volte prima di scrivere un rapporto sul bug

Il tuo bug dovrebbe essere riproducibile. Assicuratevi che i vostri passi siano abbastanza robusti da riprodurre il bug senza alcuna ambiguità. Se il vostro bug non è riproducibile ogni volta, potete comunque segnalare un bug menzionando la natura periodica del bug.

#3) Testate la stessa occorrenza del bug su altri moduli simili

A volte lo sviluppatore usa lo stesso codice per diversi moduli simili. Quindi ci sono maggiori possibilità che il bug in un modulo si verifichi anche in altri moduli simili. Puoi anche provare a trovare la versione più grave del bug che hai trovato.

#4) Scrivi un buon riassunto del bug

Il riassunto del bug aiuterà gli sviluppatori ad analizzare rapidamente la natura del bug. Un rapporto di scarsa qualità aumenterà inutilmente il tempo di sviluppo e di test. Comunicate bene con il vostro riassunto di bug. Tieni a mente che il riassunto del bug è usato come riferimento per cercare il bug nell’inventario dei bug.

#5) Leggi il rapporto del bug prima di premere il pulsante Invia

Leggi tutte le frasi, le formulazioni e i passi che sono usati nel rapporto del bug. Guarda se qualche frase crea ambiguità che può portare a un’interpretazione errata. Parole o frasi fuorvianti dovrebbero essere evitate per avere una segnalazione chiara.

#6) Non usare un linguaggio abusivo

È bello che tu abbia fatto un buon lavoro e trovato un bug ma non usare questo credito per criticare lo sviluppatore o per attaccare qualsiasi individuo.

Conclusione

Nessun dubbio che il tuo rapporto di bug dovrebbe essere un documento di alta qualità.

Concentrati sulla scrittura di buoni rapporti di bug e dedica del tempo a questo compito perché questo è il principale punto di comunicazione tra il tester, lo sviluppatore e il manager. I manager dovrebbero creare una consapevolezza nel loro team che scrivere un buon rapporto di bug è la responsabilità principale di ogni tester.

.