Tenere traccia dei bug

Durante l'esecuzione di test per verificare i requisiti, è probabile che si riscontrino bug. Utilizzare l'elemento di lavoro bug per descrivere e tenere traccia dello stato di ogni bug riscontrato.

Per ulteriori informazioni su come creare elementi di lavoro bug, vedere Esecuzione di test manuali tramite Team Web Access. Quando si riscontrano bug, seguire il processo descritto in questo argomento per classificarli in ordine di priorità, in modo da garantirne la correzione e per disporre di una registrazione delle attività e delle decisioni interessate.

Valutare i bug

È consigliabile tenere riunioni di valutazione a intervalli definiti dopo l'inizio delle attività di sviluppo e dei test nel progetto. La frequenza e la durata delle riunioni varia a seconda della situazione.

Le riunioni di valutazione dei bug vengono in genere gestite da un responsabile del progetto e vi partecipano i responsabili del team e talvolta analisti e parti interessate che possono presentare i rischi specifici del progetto. Il responsabile del progetto può utilizzare query Bug attivi per i bug nuovi e riaperti per generare un elenco di bug da valutare.

Prima dell'inizio della valutazione, individuare un set di criteri per determinare i bug da correggere e la relativa priorità. I criteri identificheranno in genere la gravità dei bug, i bug associati a funzionalità di valore significativo (o con un costo opportunità dei rinvii significativo) o ad altri rischi del progetto.

I criteri di valutazione devono essere archiviati nella cartella Documenti del progetto team. Il documento verrà aggiornato nel tempo. Si presuppone che per il progetto sia attivato il controllo della versione e che sia possibile recuperare i criteri specifici utilizzati in qualsiasi momento nel progetto come evidenza dell'esecuzione del controllo e della valutazione.

Nelle fasi iniziali del progetto si stabilirà probabilmente di correggere la maggior parte dei bug valutati. Con il procedere del progetto, tuttavia, è possibile aumentare i criteri (o il livello dei criteri) di valutazione per ridurre il numero di bug corretti.

Aumentare il livello dei criteri di valutazione e mantenere non corretti i bug segnalati sono approcci che comportano un compromesso. In base a tale compromesso, la correzione del bug è meno importante del raggiungimento degli obiettivi relativi ad ambito del progetto, budget e pianificazione.

Utilizzare i criteri per determinare i bug da correggere e come impostarne stato, priorità, gravità e altri campi. Per impostazione predefinita, il modello fornisce quattro priorità: da 1 che corrisponde a "da correggere", a 4 che indica "non importante". Se si modificano le definizioni nel modello di processo, è necessario aggiornare di conseguenza le linee guida, il testo della Guida e tutti i documenti sui criteri.

Correggere i bug

Dopo che un bug ha superato la valutazione ed è stato classificato in ordine di priorità, deve essere assegnato a uno sviluppatore per ulteriori indagini.

L'elemento di lavoro bug include una scheda per i passaggi di ripetizione, in cui devono essere disponibili tutte le informazioni per riprodurre il bug. È inoltre possibile utilizzare IntelliTrace per semplificare la riproduzione di bug difficili. Per ulteriori informazioni su IntelliTrace, vedere Rilevamento della qualità del software.

Dopo aver stabilito le azioni da intraprendere, lo sviluppatore dovrà annotare le proprie decisioni nell'elemento di lavoro bug.

Stabilire la correzione

Collaborando con altri membri del team, lo sviluppatore può consigliare una correzione che comporta implicazioni per altre sezioni del codice e che può richiedere test di regressione significativi. Qualsiasi conversazione correlata alla valutazione dei rischi di tale correzione deve essere registrata nella cronologia degli elementi di lavoro bug, in quanto consente di documentare con evidenze l'avvenuta esecuzione dell'analisi delle decisioni e della gestione dei rischi per un controllo o una valutazione SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Per ulteriori informazioni su CMMI, vedere Informazioni generali su CMMI.

Aggiornare ed eseguire unit test per correggere il bug

Gli unit test consentono di verificare la corretta implementazione di un'unità di codice. Tramite la scrittura e l'esecuzione di unit test è possibile identificare i bug prima dell'avvio dei test e, di conseguenza, di ridurre i costi correlati al controllo della qualità. Gli sviluppatori devono scrivere unit test per tutto il codice che verrà scritto come parte dell'implementazione di un'attività di sviluppo o di una correzione per il bug. Per ulteriori informazioni, vedere Verifica del codice tramite unit test.

Potrebbe essere preferibile scrivere gli unit test prima di apportare qualsiasi correzione al codice se è stata definita una strategia di sviluppo che prevede l'esecuzione di test come prima operazione. Questo tipo di strategia è quella preferita dagli sviluppatori di software Agile. CMMI non richiede la scrittura degli unit test in una sequenza specifica, ma solo la realizzazione di un'efficace verifica della funzionalità.

Per una valutazione CMMI, è necessaria l'evidenza dell'esecuzione e della scrittura degli unit test. Assicurarsi di collegare i test agli elementi di lavoro attività per la correzione del codice e di collegare tali attività all'elemento di lavoro bug. In questo modo, si disporrà della tracciabilità delle evidenze richieste da un responsabile della valutazione SCAMPI.

Rivedere ed effettuare il refactoring del codice per correggere il bug

La revisione del codice garantisce che il codice nuovo o modificato soddisfi un livello di qualità stabilito prima di essere integrato nella compilazione giornaliera. Le considerazioni relative alla qualità riguardano standard di codifica, conformità ad architettura e progettazione, prestazioni, leggibilità e sicurezza. Le revisioni del codice forniscono inoltre nozioni aggiuntive provenienti da altri sviluppatori relative al modo in cui il codice deve essere scritto. Per ulteriori informazioni su come rivedere il codice ed eseguirne il refactoring, vedere Implementare le attività di sviluppo.

Chiudere i bug

Quando un bug viene corretto, deve essere assegnato a un tester che verifichi la risoluzione del problema prima della chiusura dell'elemento di lavoro bug.

Verifica di una correzione

Per verificare una correzione, il tester deve tentare di riprodurre il bug, individuare qualsiasi ulteriore comportamento imprevisto e, se necessario, riattivare il bug.

Durante la verifica della risoluzione di un bug, è possibile che il bug non risulti completamente corretto o che non si concordi con la soluzione. In questo caso, è necessario discutere il bug con la persona che lo ha risolto, raggiungere un accordo e, se possibile, riattivare il bug. Se si riattiva un bug, assicurarsi di includere i motivi della riattivazione nella descrizione del bug, in modo da non perdere queste informazioni.

Chiusura dell'elemento di lavoro bug

Un bug viene chiuso per molti motivi. In un caso semplice, la correzione del bug è stata verificata e il bug può essere chiuso. È possibile, tuttavia, rinviare un bug alla versione successiva del prodotto, dimostrarlo come non riproducibile o confermarlo come duplicato. È necessario documentare ciascuno di questi motivi e quindi chiudere il bug correttamente per garantire che non vi siano incertezze sul motivo per cui è stato chiuso.