L'anatomia di una buona segnalazione di bug

Per quasi un secolo e mezzo, gli ingegneri hanno chiamato "bug" piccoli difetti nelle macchine. Al giorno d'oggi, "bug" viene utilizzato per problemi sia hardware che software in computer e gadget. I bug del computer sono in circolazione da un bel po 'di tempo e con loro sono arrivati ​​anche i bug report.

La prima segnalazione di bug del computer è stata documentata il 9 settembre 1947 da Grace Murray Hopper. Ha riferito che una vera falena era bloccata tra i contatti del relè nel computer di Harvard Mark II. Il bug è stato registrato sul registro del computer.

Maggiori informazioni sulla prima segnalazione di bug possono essere trovate qui.

Da allora, le segnalazioni di bug sono state una parte importante dell'intero processo di QA. Rimangono lo strumento principale per la segnalazione di errori nei codici di programmazione.

Questo articolo copre ciò che deve essere incluso in una buona segnalazione di bug. Ci saranno anche un paio di esempi per segnalazioni di bug buoni e cattivi, inclusa una breve analisi di ciascuno.

Che cos'è una segnalazione di bug?

Nello sviluppo di siti Web, una segnalazione di bug è lo strumento principale utilizzato per indicare che un determinato pezzo di codice non funziona come previsto. Ci sono un sacco di diversi esempi di "bug" là fuori, ma per citarne alcuni:

• Un sito web che si arresta in modo anomalo a causa dell'utilizzo di troppe risorse di sistema
• Le immagini appaiono strane su alcuni browser o dispositivi
• Un negozio online mostra prezzi errati per alcuni prodotti
• Una funzione non funziona in base ai requisiti del cliente

Lo scopo principale di una segnalazione di bug è consentire al team di sviluppo di riprodurre il problema che è stato segnalato dal team QA. È importante disporre di tutte le informazioni richieste per semplificare il processo di debug e correzione.

Le segnalazioni di bug vengono utilizzate non solo per segnalare problemi, ma anche per suggerire nuove funzionalità e miglioramenti . Pertanto, la maggior parte delle linee guida su cosa dovrebbe includere una buona segnalazione di bug si applicherebbero anche ai suggerimenti.

Articolo correlato: Come sviluppare un piano di garanzia della qualità per il tuo sito Web WordPress

Cosa dovrebbe includere una segnalazione di bug?

Una buona segnalazione di bug deve includere informazioni precise sul problema che si è verificato. Affinché ciò avvenga, devono essere presenti i seguenti elementi, come nel modello utilizzato da noi qui a DevriX. In Devrix, il modello per le segnalazioni di bug si basa su questi elementi. È stato dimostrato che forniscono informazioni sufficienti sui problemi riscontrati.

• Titolo : dovrebbe servire come un breve riassunto di quale sia il problema. È importante che il titolo sia specifico sulla natura del problema. È la prima cosa che vede uno sviluppatore.
• Stato : questo è un indicatore dello stato in cui si trova la segnalazione di bug. Possono esserci diversi tipi di statue., A seconda del software di gestione utilizzato (come Jira, Asana, Trello, Mantis, ecc.). Qualche esempio:
  • Da assegnare - Quando è ancora da stabilire chi indagherà sui problemi nel rapporto.
  • In corso : quando uno sviluppatore sta lavorando alla risoluzione del bug segnalato. Questo stato viene utilizzato anche quando un aggiornamento è attualmente in fase di test.
  • Completo : segno che il bug segnalato è stato risolto.
• Priorità : indica l'urgenza di un bug segnalato rispetto ad altre attività e problemi. La priorità di un bug è legata alla gravità di un bug in quanto misura l'impatto sul sistema testato. Le priorità più comuni sono:
  • Critico : utilizzato per problemi in cui tutte le altre attività devono essere interrotte e tutti gli sforzi sono concentrati nella risoluzione della situazione. Ciò è dovuto al fatto che tali problemi hanno un impatto importante sul progetto per il quale vengono segnalati e potrebbero comportare perdite per l'azienda.
  • Alto : utilizzato per problemi che dovrebbero essere risolti prima, piuttosto che dopo. Non hanno un impatto così importante, ma se non ci sono problemi critici, dovrebbero essere risolti al più presto.
  • Medio : utilizzato per problemi che non hanno un impatto importante sulle funzionalità principali. Sarebbe bello risolverli. Tali problemi devono essere risolti dopo quelli con priorità maggiore.
  • Basso : utilizzato quando il bug segnalato è minore e non ha alcun effetto sulla funzionalità di base. Potrebbe essere un errore grammaticale in un post sul blog o il colore sbagliato per un pulsante.
• Gravità : utilizzato per mostrare il livello di impatto del bug segnalato sul sistema testato. La classificazione più comune per la gravità di un bug è:
  • Critico : una funzionalità di base non funziona o l'intero software non funziona.
  • Maggiore : una o più funzionalità di base sono interessate dal bug. Per questo motivo, il software testato non produce i risultati desiderati. A differenza dei bug con gravità critica, ci saranno funzionalità che funzionano come previsto.
  • Moderato : non vi è alcun impatto sulle funzionalità principali del software testato. Uno o più componenti sono interessati, determinando un comportamento incoerente.
  • Minore : l'impatto sul software testato è minore.
  • Banale : i bug con questa gravità non influiscono sulla funzionalità del software. Questi potrebbero essere piccoli difetti visivi, traduzioni mancanti, un messaggio di conferma non funzionante, ecc.
• Dettagli bug : i dettagli contengono informazioni importanti su dove si è verificato il problema segnalato. Le seguenti informazioni dovrebbero essere incluse (sebbene organizzazioni diverse possano richiedere dettagli (bug) diversi):
  • Il browser in cui è stato riscontrato il bug (è meglio includere anche la versione)
  • Il sistema operativo - Potrebbe essere un problema, osservato solo in Windows. Ciò include anche sistemi operativi mobili come Android, iOS e PadOS
  • Il ramo - Questo è per gli aggiornamenti non rilasciati (nuove funzionalità o aggiornamenti che risolvono altri bug segnalati). Il ramo contiene solo commit specifici, rilevanti per una funzionalità. Questo viene fatto in modo che un cambiamento non interferisca con il lavoro di altre persone sullo stesso progetto
  • Versione : se il software testato è un'applicazione desktop o mobile. è consigliabile includere la versione in cui è stato segnalato il bug.
• Descrizione del bug : lo specialista del QA deve fornire una spiegazione accurata del problema osservato, insieme ai passaggi necessari per riprodurre il problema. Lo specialista dovrebbe anche descrivere quale dovrebbe essere effettivamente il risultato atteso. Tutti questi sono importanti per aiutare il team di sviluppo a capire qual è il problema, quali azioni devono essere eseguite per riprodurlo e quale dovrebbe essere il comportamento corretto.
• Allegati / Screenshot - Un allegato / screenshot consente allo specialista di vedere quale e spesso dove si trova il problema. Può inoltre fornire allo specialista del controllo qualità i passaggi eseguiti per attivare il problema.
• Commenti : la sezione commenti non viene generalmente utilizzata quando viene creata una nuova segnalazione di bug, ma è importante condividere alcune parole su ciò che deve essere incluso nei commenti degli sviluppatori (e in eventuali commenti successivi) quando viene inviata una correzione di bug al Team di controllo qualità per i test. Gli sviluppatori devono includere i seguenti elementi:
  • Collegamento al commit che contiene l'aggiornamento.
  • Spiega cosa fa l'aggiornamento.
  • Se è necessario eseguire passaggi di configurazione, è importante spiegarli.
  • Allega eventuali screenshot / screencast che mostrano l'aggiornamento in azione.
  • Includere eventuali note che lo specialista del QA deve tenere in considerazione durante il test dell'aggiornamento.

Risorse correlate : il lavoro di garanzia della qualità è una parte essenziale del lavoro su ogni sito web. Ecco perché passare attraverso la lunga e dettagliata fase di test, correggere bug e regressioni e stabilizzare la piattaforma per il lancio è legato a quanto costerà il sito web.

Scrittura di attività per suggerimenti e nuove funzionalità

Durante l'esecuzione dei test di QA, i tester esperti di solito escogitano idee per migliorare il progetto. Allo stesso modo, i proprietari del progetto e i project manager devono ricevere le richieste dei clienti (per funzionalità, correzioni, miglioramenti) che devono essere condivise con il team di sviluppo.

A differenza dei rapporti sui bug, lo scopo delle attività Suggerimenti e Nuove funzionalità è spiegare le richieste dei clienti o le idee di miglioramento che hanno il potenziale per migliorare il progetto (come l'implementazione di un aggiornamento delle prestazioni, l'aggiunta di una funzionalità che consentirebbe una migliore interazione con gli utenti , eccetera).

In entrambi i casi è importante fornire una descrizione chiara della funzionalità che deve essere implementata:

• Nuove funzionalità, richieste dal cliente - È importante che il proprietario del progetto / project manager capisca di cosa ha bisogno il cliente, riveda tutti i modelli forniti e discuta eventuali dettagli aggiuntivi. Una volta che è chiaro cosa vuole il cliente, è più facile spiegare al team di sviluppo cosa deve fare.
• Suggerimenti : è importante avere una visione chiara del progetto nel suo insieme e di come la funzionalità suggerita lo migliorerà. In questo modo sarà più facile spiegare l'idea e i vantaggi che porterebbe.

Segnalazioni di bug buoni e cattivi: esempi

Dichiarazione di non responsabilità : i seguenti esempi sono tratti da un progetto di corso QA a cui ha preso parte l'autore. L'obiettivo è analizzare gli errori che sono stati fatti nei rapporti e come possono essere evitati.

Esempio 1 :

Ecco un esempio di una segnalazione di bug ben scritta. Include tutti gli attributi discussi sopra.

Tuttavia, c'è un problema con esso: il suo titolo non fornisce un'idea precisa del problema segnalato. L'immagine del prodotto mancante potrebbe trovarsi ovunque nel web store testato.

Un titolo migliore è "Immagini dei prodotti mancanti nella sezione" Le persone che hanno acquistato questo articolo hanno acquistato anche "". In questo modo il team di sviluppo avrebbe un'idea di cosa tratta il rapporto dal titolo stesso.

Esempio 2 :

Questo è un esempio di una segnalazione di bug complessivamente scritta male. I problemi principali con questo esempio sono:

• Il titolo non è specifico su dove sia esattamente il prezzo mancante
• La descrizione non specifica dove è stato osservato esattamente il problema.
• Il risultato atteso non spiega effettivamente quale sia il comportamento corretto.

Le segnalazioni di bug scritte male costringono il team di sviluppo a dedicare tempo non necessario a capire qual è il problema e dove si trova il problema segnalato. Il team spesso deve ricorrere a chiedere allo specialista QA che ha segnalato il bug di chiarire eventuali dettagli mancanti ...

Esempio 3 :

Questo è un buon esempio di una segnalazione di bug scritta correttamente. Fornisce al team di sviluppo un'idea chiara di dove si trova il problema e come può essere riprodotto.

Un piccolo problema con questo rapporto è che il problema segnalato non interrompe effettivamente il processo di test, il che significa che la gravità e la priorità assegnate non sono corrette. Se lo specialista QA avesse esaminato meglio il problema, avrebbe notato che esiste una soluzione alternativa.

Questa soluzione alternativa avrebbe consentito il completamento del processo di registrazione dell'account. È di grande importanza indagare su un problema prima che venga segnalato in modo che non vengano esclusi dettagli importanti e che sia possibile assegnare la gravità e la priorità corrette.

In conclusione

Una segnalazione di bug ben scritta da parte dei QA è fondamentale affinché il team di sviluppo possa capire qual è il problema e come dovrebbe essere risolto. Perché ciò avvenga, ricorda sempre quanto segue:

• Il titolo della segnalazione di bug deve riepilogare il problema segnalato.
• Fornisci dettagli accurati: la piattaforma in cui viene rilevato il problema, il browser (per le applicazioni Web), il ramo in cui viene rilevato il problema.
• Fornisci una descrizione chiara di quale sia il problema segnalato.
• Assicurati che i passaggi di riproduzione siano accurati.
• Annotare quale dovrebbe essere il comportamento previsto rispetto a ciò che viene effettivamente osservato al momento della creazione del report.
• Ricordarsi di assegnare la priorità e la gravità delle attività appropriate.
• Allega tutti i file rilevanti: screenshot, screencast, log, ecc.
• Includere eventuali informazioni aggiuntive che potrebbero aiutare il team di sviluppo a risolvere il problema.