Software Testing - il contenuto di un Bug

Ingrandisci immagine

Quando un tester trova un difetto, lui / lei ha bisogno di segnalare un bug e inserire alcuni campi, che aiuta a identificare univocamente il bug riportato dal tester. I contenuti di un bug sono come indicato di seguito:

Progetto: Nome del progetto in base al quale la sperimentazione è in corso.

Oggetto: Descrizione del bug in breve che aiuterà a individuare il bug. Si inizia in genere con il numero identificativo del progetto / string. Questa stringa deve essere sufficientemente chiaro per aiutare il lettore nella anticipare il problema / difetto per il quale il bug è stato segnalato.

Descrizione: descrizione dettagliata del bug. Ciò include generalmente le fasi che sono coinvolti nel caso di test ed i risultati effettivi. Al termine della sintesi, il passo in cui il caso test fallisce viene descritta insieme con il risultato effettivo ottenuto e risultato atteso.

Oggetto: Questo campo contiene alcune informazioni chiave sul bug, che possono aiutare a ridurre al minimo il numero di record da cercare.

Riconosciuto da: Nome del tester che ha rilevato / segnalato il bug.

Assegnato a: nome dello sviluppatore che dovrebbe risolvere il bug. Generalmente questo campo contiene il nome del capo sviluppatore del gruppo, che poi delega il compito di membro della sua squadra e cambia il nome di conseguenza.

Piombo Test: Nome del leader del team di test, sotto il quale il tester riporta il bug.

Riconosciuto nella versione: Questo campo contiene le informazioni sulla versione del software in cui è stato rilevato il bug.

Chiuso nella versione: Questo campo contiene le informazioni sulla versione del software in cui è stato corretto il bug.

Data rilevato: Data in cui il bug è stato rilevato e segnalato.

Prevista data di chiusura: data in cui si prevede il bug da chiudere. Questo dipende dalla gravità del bug.

Data effettiva di Chiusura: Come suggerisce il nome, la data effettiva di chiusura alla data di bug cioè in cui è stato corretto il bug e ripetere il test con successo.

Priorità: la priorità del bug fixing. Questo dipende in particolare alla funzionalità che è sfavorevole. In generale Medio, Basso, Alto, urgente sono il tipo di gravità che vengono utilizzati.

Gravità: Si tratta in genere di un campo numerico, che mostra la gravità del bug. Essa può variare da 1 a 5, dove 1 è elevata severità e 5 è il più basso.

Status: questo campo viene visualizzato lo stato corrente del bug. Lo stato di New viene assegnato automaticamente ad un bug quando è la prima volta riportato dal tester, oltre lo stato viene modificato assegnato, Open, ripetere il test, Retest attesa, attesa Rifiuta, Rifiutato, Chiuso, rinviata, ecc differita come da avanzamento del processo di bug fixing.

Bug ID: Questo è un numero unico ID cioè creata per il bug al momento della segnalazione, che identifica in modo univoco il bug.

Allegato: A volte è necessario allegare screen-shots per la funzionalità testato tester che può aiutare a spiegare il test che aveva fatto e aiuta anche gli sviluppatori a ricreare la condizione simile test.

Banco di prova non riuscita: Questo campo contiene il caso di test che è riuscita per il bug.

Uno qualsiasi dei campi sopra indicati può essere resa obbligatoria, in cui il tester deve inserire un dato in vigore al momento di riportare un bug. Fare un campo obbligatorio o facoltativo dipende dalle esigenze aziendali e può avvenire in qualsiasi punto del tempo in un progetto di test del software.

(Nota: Tutti i contenuti arruolati sopra sono generalmente presenti per ogni bug segnalato in un bug strumento di segnalazione In alcuni casi (per le personalizzate bug-reporting tools) il numero dei campi e del loro significato può cambiare secondo le esigenze aziendali.. )