Rapporto Tendenze del bug

Articolo
06/10/2015

Il rapporto Tendenze del bug consente di tenere traccia della frequenza con cui il team individua e risolve i bug. Questo rapporto mostra una media mobile di bug che vengono segnalati, risolti e chiusi nell'arco del tempo. Quando si gestisce un team numeroso o un elevato numero di bug, il monitoraggio settimanale del rapporto Tendenze del bug consente di comprendere la capacità del team di individuare, risolvere e chiudere i bug.

Per informazioni sulle modalità di accesso, di aggiornamento o di gestione dei rapporti, vedere Rapporti (SQL Server Reporting Services).

Nota

Per questo rapporto è previsto che sia stato eseguito il provisioning della raccolta di progetti team contenente il progetto team con SQL Server Reporting Services.Questo rapporto non è disponibile se Report Rapporti non viene visualizzato all'apertura di Team Explorer ed espandendo il nodo del progetto team.

In questo argomento

Dati contenuti nel rapporto
Impostazione della durata dell'iterazione
Interpretazione del rapporto
Filtro del rapporto

È possibile utilizzare questo rapporto per rispondere alle domande seguenti:

Quanti bug al giorno vengono segnalati, risolti e chiusi dal team?
Quale è la tendenza complessiva alla quale il team elabora i bug?
La frequenza di attivazione e di risoluzione dei bug diminuisce verso la fine dell'iterazione come previsto?

Autorizzazioni necessarie

Per visualizzare il rapporto, è necessario disporre del ruolo Browser in SQL Server Reporting Services o appartenere a un gruppo a cui sia assegnato questo ruolo. Per ulteriori informazioni, vedere Aggiungere utenti ai progetti team o Gestione delle autorizzazioni.

Dati contenuti nel rapporto

Il rapporto Tendenze del bug calcola una media mobile del numero di bug che sono stati aperti, risolti e chiusi dal team sulla base dei filtri precedentemente specificati nel rapporto. La media mobile è basata sui sette giorni precedenti la data per la quale è calcolata. In pratica, il rapporto calcola la media del numero di bug in ciascuno stato per ognuno dei sette giorni precedenti la data, quindi divide il risultato per sette. I dati sono derivati dal data warehouse.

Nell'illustrazione che segue viene mostrato un esempio di rapporto Tendenze del bug.

Esempio di report Tendenze del bug

In questo rapporto vengono visualizzati fino a tre grafici a linee e ogni grafico rappresenta le medie mobili dei numeri di bug attivati, risolti e chiusi.

Il rapporto può essere filtrato nei seguenti modi:

Modificando le date di inizio e di fine del rapporto.
Filtrando i bug conteggiati nel rapporto tramite la specifica dei percorsi di iterazione e di area, lo stato, la priorità o la gravità dei bug.

Per ulteriori informazioni, vedere Filtro del rapporto più avanti in questo argomento.

Attività necessarie per tenere traccia dei bug

Affinché il rapporto Tendenze del bug sia utile e accurato, il team deve effettuare le attività seguenti:

Definire i bug e specificarne i percorsi Iterazione e Area.
Aggiornare lo Stato di ogni bug man mano che viene corretto, verificato e chiuso.
Specificare la Priorità e la Gravità di ogni bug durante la valutazione.

È possibile utilizzare la cartella di lavoro Valutazione per aggiornare rapidamente l'iterazione, l'area, lo stato, la priorità e la gravità dei bug. Per ulteriori informazioni, vedere Cartella di lavoro Valutazione.

Impostazione della durata dello sprint o iterazione

Per capire le tendenze del bug per l'iterazione corrente, le date di inizio e di fine per il rapporto devono corrispondere a quelle del ciclo di iterazione corrente.

Per modificare la durata dell'iterazione

Fare clic sull'icona calendario accanto a Inizio iterazione (data) o a Fine iterazione (data) e selezionare una data.
Fare clic su Visualizza rapporto.

Interpretazione del rapporto

È necessario prevedere delle variazioni nella frequenza dei bug in base alla fase del ciclo di sviluppo del prodotto in cui ci si trova. Il team dovrebbe trovare meno bug nelle prime iterazioni che nelle iterazioni più tardive. Il team dovrebbe chiudere la maggior parte dei bug nelle iterazioni che si trovano verso la fine di un ciclo del prodotto.

La frequenza dei bug può essere interpretata meglio analizzandola in relazione a tutte le attività del progetto team corrente e le altre metriche fornite dai rapporti Stato del bug e Riattivazioni bug. Ad esempio, il team potrebbe trovare rapidamente dei bug in codice non corretto, in codice appena integrato, tramite dei test approfonditi o durante un evento insolito quale un bug bash. D'altra parte i bug sono più difficili da trovare in un prodotto di alta qualità ma con dei test inefficaci. È possibile utilizzare le metriche per il code coverage, la varianza del codice e la frequenza dei test per determinare ulteriormente il significato delle tendenze del bug.

Man mano che il prodotto si stabilizza verso la fine del ciclo produttivo, il team dovrebbe trovare meno bug.

Il rapporto Tendenze del bug potrebbe mostrare uno o più degli indicatori descritti nella colonna sinistra della tabella seguente. È possibile rivedere le domande nella colonna di destra per indirizzare le aree in modo più dettagliato.

Indicatore	Domande
Il team sta trovando più o meno lo stesso numero di bug in periodi di tempo successivi. Se il team trova lo stesso numero di bug in più settimane o iterazioni successive, potrebbe essere utile esaminarne la causa sottostante. All'inizio del ciclo di test, i test potrebbero non essere sufficientemente rigorosi o avanzati da consentire l'individuazione di molti bug. Nelle prime iterazioni, questa situazione è prevedibile. Tuttavia, a mano a mano che il prodotto matura, i test devono esercitare scenari e integrazioni più ampi.	I test case sono adatti a testare le storie utente in fase di sviluppo? I test sono diventati obsoleti o stanno verificando la funzionalità errata? Il team del testing sta testando con rigore ogni storia utente?
Il team trova numerosi bug in ogni periodo di tempo. Il team potrebbe individuare con facilità bug in codice approssimativo, in codice appena integrato, effettuando test efficaci oppure durante un evento specifico, come ad esempio un bug bash.	Le metriche per il code coverage, la varianza del codice o lo stato di avanzamento del test indicano un problema di codice o di test?
Il team trova pochi bug in ogni periodo di tempo. Il team potrebbe incontrare difficoltà a trovare i bug in una soluzione di alta qualità o se utilizza test inefficaci.	Le metriche per il code coverage, la varianza del codice o lo stato di avanzamento del test indicano un problema di codice o di test?
Il team risolve numerosi bug in ogni periodo di tempo. Una elevata frequenza di risoluzione indica in genere che il team sta svolgendo un buon lavoro.	I bug risolti vengono prontamente chiusi? La frequenza di chiusura dei bug deve riflettere la frequenza di risoluzione. Le riattivazioni dei bug rimangono entro i limiti previsti?
Il team risolve rapidamente i bug ma non li chiude. I membri del team che sono assegnati alla verifica delle correzioni dei bug potrebbero non essere sufficienti oppure potrebbero essere occupati in altre priorità e non avere quindi tempo per chiudere i bug risolti.	Le risorse del test sono sovrallocate? Il team deve rivedere le priorità di test?

Versione non problematica del rapporto

Un rapporto Tendenze del bug sano mostra che il team trova più bug all'inizio di un ciclo di sviluppo e meno bug verso la fine di una versione del prodotto. Il team deve risolvere e chiudere più bug verso la fine del progetto.

Quando il team risolve bug più velocemente di quanto li trovi, il numero di bug attivi inizierà a diminuire. Quando il team inizia a trovare meno bug, il prodotto diventa stabile.

Versione problematica del rapporto

Un rapporto Tendenze del bug problematico potrebbe mostrare che il team sta trovando bug più rapidamente man mano che si avvicina la data di spedizione e li sta risolvendo più lentamente. In questa situazione, il backlog dei bug del team aumenta perché i bug non vengono corretti e sarebbe utile esaminare le cause. Nell'illustrazione che segue viene mostrato un rapporto relativo a un team che trova molti bug, ne risolve meno di quanti ne trovi e ne chiude meno di quanti ne risolva.

Versione problematica del report Tendenze del bug

Applicazione di filtri al rapporto e modifica della visualizzazione

È possibile filtrare il rapporto Tendenze del bug o modificarne la visualizzazione nei seguenti modi:

Modificando le date di inizio e di fine del rapporto.
Filtrando i bug conteggiati nel rapporto tramite la specifica dei percorsi di iterazione e di area, lo stato, la priorità o la gravità dei bug.

Nell'illustrazione che segue vengono mostrati i filtri disponibili.

Filtri per il report Tendenze del bug

Per filtrare i bug conteggiati nel rapporto

Eseguire una o entrambe le azioni riportate di seguito.
- Negli elenchi Iterazione e Area selezionare la casella di controllo relativa a ciascuna iterazione o area del prodotto che si desidera includere.
- Negli elenchi Stato, Priorità o Gravità, selezionare la casella di controllo di ogni stato, priorità e gravità da includere.
Fare clic su Visualizza rapporto.