Definire, acquisire, valutare e gestire bug software in Azure Boards

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Come si tiene traccia e si gestiscono i difetti nel codice? Come assicurarsi che i problemi software e i commenti dei clienti vengano risolti rapidamente per supportare distribuzioni software di alta qualità? E come fai a fare buoni progressi sulle nuove funzionalità e affrontare il tuo debito tecnico?

È necessario almeno un modo per acquisire i problemi software, classificarli in ordine di priorità, assegnarli a un membro del team e tenere traccia dello stato di avanzamento. E si vogliono gestire i difetti del codice in modi che si allineano alle procedure Agile.

Per supportare questi scenari, Azure Boards fornisce un tipo di elemento di lavoro specifico per tenere traccia dei difetti di codice denominati Bug. Gli elementi di lavoro di bug condividono tutte le funzionalità standard di altri tipi di elementi di lavoro con altri altri. Per una panoramica delle funzionalità standard, vedere Tenere traccia delle storie utente, dei problemi, dei bug, delle funzionalità e delle epiche.

I bug forniscono anche le funzionalità aggiuntive seguenti:

• Opzioni per ogni team per scegliere come tenere traccia dei bug
• Strumenti di test per acquisire bug
• Integrazione predefinita in Azure DevOps per tenere traccia dei bug collegati a compilazioni, versioni e test

Nota

I tipi di elementi di lavoro bug non sono disponibili con il processo Basic. Il processo Basic tiene traccia dei bug come Problemi ed è disponibile quando si crea un nuovo progetto da Azure DevOps Services o da Azure DevOps Server 2019.1 o versioni successive.

Prerequisiti

• È necessario essere aggiunti a un progetto.
• Per visualizzare o modificare gli elementi di lavoro, è necessario disporre degli elementi di lavoro Visualizza in questo nodo e Modificare gli elementi di lavoro in questo nodo le autorizzazioni impostate su Consenti. Per impostazione predefinita, il gruppo Collaboratori dispone di questo set di autorizzazioni. Per altre informazioni, vedere Impostare le autorizzazioni e l'accesso per il rilevamento del lavoro.
• Per aggiungere nuovi tag da aggiungere agli elementi di lavoro, è necessario avere accesso di base o superiore e disporre delle autorizzazioni create new tag definition impostate su Consenti a livello di progetto. Per impostazione predefinita, il gruppo Collaboratori dispone di questo set di autorizzazioni. Anche se l'autorizzazione è impostata in modo esplicito per uno stakeholder, non dispone dell'autorizzazione per aggiungere nuovi tag, perché non è consentito tramite il livello di accesso. Per altre informazioni, vedere Informazioni di riferimento rapido sull'accesso di tipo Stakeholder.
• Tutti i membri del progetto, anche i membri del gruppo Lettori , possono inviare messaggi di posta elettronica contenenti elementi di lavoro.

Suggerimento

Per segnalare un bug, un utente deve avere almeno l'accesso agli stakeholder e Modificare gli elementi di lavoro in questo nodo impostato su Consenti per il percorso area in cui aggiunge il bug. Per altre informazioni, vedere Impostare le autorizzazioni e l'accesso per il rilevamento del lavoro

Tipo di elemento di lavoro bug

L'immagine seguente mostra il tipo di elemento di lavoro Bug per il processo Scrum. Il tipo di elemento di lavoro Bug per i processi Agile e CMMI tiene traccia di informazioni simili. È progettato per essere visualizzato nel backlog del prodotto insieme ai requisiti o al Taskboard insieme alle attività.

Nota

Le immagini visualizzate dal portale Web possono differire dalle immagini visualizzate in questo articolo. Queste differenze derivano dagli aggiornamenti apportati all'app Web, alle opzioni abilitate dall'utente o dall'amministratore e dal processo scelto durante la creazione del progetto: Agile, Basic, Scrum o CMMI. Il processo Basic è disponibile con Azure DevOps Server 2019 Update 1 e versioni successive.

Campi specifici dei bug

Il tipo di elemento di lavoro Bug usa alcuni campi specifici del bug. Per acquisire sia il problema iniziale che le individuazioni in corso, usare i campi descritti nella tabella seguente. Per informazioni sui campi specifici del bug definito per il processo CMMI (Capability Maturity Model Integration), vedere Bug, problemi e informazioni di riferimento sul campo rischi. Per informazioni su tutti gli altri campi, vedere Indice dei campi dell'elemento di lavoro.

---

Campo, gruppo o scheda

Utilizzo

---

Passaggi da riprodurre
(nome descrittivo=Passaggi di riproduzione)

Usare per acquisire informazioni sufficienti in modo che altri membri del team possano comprendere completamente il difetto del codice. Includere le azioni eseguite per trovare o riprodurre il bug e il comportamento previsto.

---

Informazioni di sistema
Trovato nella compilazione

Informazioni sulla configurazione del software e del sistema rilevanti per il bug e i test da applicare. I campi Informazioni di sistema e Trovati in Compilazione vengono compilati automaticamente quando si crea un bug tramite uno strumento di test. Questi campi specificano informazioni sull'ambiente software e sulla compilazione in cui si è verificato il bug. Per altre informazioni, vedere Testare configurazioni diverse.

---

Criteri di accettazione

Specificare i criteri da soddisfare prima che il bug possa essere chiuso. Prima dell'inizio del lavoro, descrivere i criteri di accettazione del cliente il più chiaramente possibile. I team devono usare questi criteri come base per i test di accettazione e per valutare se un elemento è stato completato in modo soddisfacente.

---

Integrato nella compilazione

Specifica il nome della compilazione che incorpora il codice che corregge il bug. Questo campo deve essere specificato quando si risolve il bug. Per Azure DevOps locale, per accedere a un menu a discesa di tutte le compilazioni eseguite, è possibile aggiornare le FIELD definizioni disponibili in Compilazione e Integrazione in Compilazione per fare riferimento a un elenco globale. L'elenco globale viene aggiornato automaticamente con ogni compilazione eseguita. Per altre informazioni, vedere Eseguire query basate su campi di integrazione di compilazione e test.
Per informazioni su come definire i numeri di compilazione, vedere opzioni di formato del numero di build.

---

Priorità¹

• 1: il prodotto richiede una risoluzione corretta dell'elemento di lavoro prima che venga fornito e risolto presto.
• 2: Il prodotto richiede una risoluzione corretta dell'elemento di lavoro prima della spedizione, ma non deve essere risolto immediatamente.
• 3: La risoluzione dell'elemento di lavoro è facoltativa in base a risorse, tempo e rischio.

---

Gravità¹

Classificazione soggettiva dell'impatto di un bug o di un elemento di lavoro nel progetto o nel sistema software. Ad esempio: se un collegamento remoto all'interno dell'interfaccia utente, un evento raro, causa l'arresto anomalo di un'applicazione o di una pagina Web, è possibile specificare Gravità = 2 - Alta e Priorità = 3. I valori consentiti e le linee guida suggerite sono:

• 1 - Critico: deve correggere. Un difetto che causa la chiusura di uno o più componenti di sistema o il sistema completo o causa un danneggiamento esteso dei dati. E non esistono metodi alternativi accettabili per ottenere i risultati richiesti.
• 2 - Alto: prendere in considerazione la correzione. Un difetto che causa la chiusura di uno o più componenti di sistema o il sistema completo o causa un danneggiamento esteso dei dati. Tuttavia, esiste un metodo alternativo accettabile per ottenere i risultati necessari.
• 3 - Medio: (Impostazione predefinita) Un difetto che fa sì che il sistema produca risultati non corretti, incompleti o incoerenti.
• 4 - Basso: difetto secondario o cosmetico che presenta soluzioni alternative accettabili per ottenere i risultati richiesti.

---

Distribuzione

Il controllo Distribuzione supporta collegamenti a e visualizzazione di versioni che contengono elementi di lavoro. Per usare il controllo, è necessario abilitare le impostazioni per la versione. Per altre informazioni, vedere Collegare elementi di lavoro alle versioni più avanti in questo articolo.

---

Sviluppo

Il controllo Sviluppo supporta i collegamenti a e la visualizzazione di collegamenti creati agli oggetti di sviluppo. Questi oggetti includono i commit Git e le richieste pull o i set di modifiche TFVC e gli elementi con controllo delle versioni. È possibile definire collegamenti dall'elemento di lavoro o dai commit, dalle richieste pull o da altri oggetti di sviluppo. Per altre informazioni, vedere Collegare elementi di lavoro allo sviluppo più avanti in questo articolo.

---

Note:

¹ Per modificare la selezione o l'elenco a discesa del menu, vedi Personalizzare l'esperienza di rilevamento del lavoro. Il metodo di personalizzazione dipende dal modello di processo usato dal progetto.

Scegliere il modo in cui il team tiene traccia dei bug

Il team può tenere traccia dei bug come requisiti o come attività. Per supportare la scelta del team, considerare i fattori seguenti.

• Dimensioni del team. I team più piccoli possono mantenere un footprint leggero monitorando i bug come requisiti.
• Requisiti dell'organizzazione per tenere traccia del lavoro. Se il team è necessario per tenere traccia delle ore, scegliere di tenere traccia dei bug come attività.
• Modalità di organizzazione del lavoro da parte del team. Se il team si basa sul backlog del prodotto per classificare in ordine di priorità il lavoro e aggiungere bug, tenere traccia dei bug come requisiti.
• Gli strumenti che il team vuole usare, ad esempio il riquadro Pianificazione, il grafico velocità, le previsioni, il rollup e i piani di recapito. Tenere traccia dei bug come attività impedisce l'uso di diversi di questi strumenti.

La tabella seguente riepiloga le tre opzioni che i team devono tenere traccia dei bug. Per altre informazioni e per impostare l'opzione per il team, vedere Visualizzare i bug nei backlog e nelle bacheche.

---

Opzione

Scegli quando vuoi...

---

Tenere traccia dei bug come requisiti

• Classificare in ordine di priorità i bug (stack rank) insieme ai requisiti
• Stimare le attività di bug per la previsione
• Aggiornare lo stato del bug nella scheda Kanban
• Includere bug nei grafici velocità e nei diagrammi di flusso cumulativi
• Può usare lo strumento Forecast per supportare la pianificazione dello sprint
• È possibile trascinare e rilasciare bug nel riquadro Pianificazione per assegnare bug a uno sprint
• Può visualizzare bug nei piani di recapito

Nota

• I bug vengono assegnati alla categoria Requisiti

---

Tenere traccia dei bug come attività

• Stimare il lavoro per bug simili alle attività
• Aggiornare lo stato del bug nei taskboard sprint
• Collegare bug ai requisiti come elementi figlio
• È possibile trascinare e rilasciare bug nel riquadro Pianificazione per assegnare bug a uno sprint

Nota

• I bug vengono assegnati alla categoria attività
• Storie utente (Agile), Elementi backlog prodotto (Scrum) o Requisiti (CMMI) sono il tipo di elemento di lavoro padre naturale per Bug
• I bug non saranno visibili nei piani di recapito

---

I bug non vengono visualizzati nei backlog o nelle bacheche

• Gestire i bug usando query

Nota

• I bug sono associati alla categoria Bug e non verranno visualizzati nei backlog o nelle bacheche
• I bug non saranno visibili nei backlog, nelle bacheche, nei backlog sprint, nelle lavagne o nei piani di recapito
• Non è possibile trascinare e rilasciare bug nel riquadro Pianificazione per assegnare bug a uno sprint

---

Personalizzare il tipo di elemento di lavoro

È possibile personalizzare i tipi di bug e altri elementi di lavoro. In alternativa, creare tipi personalizzati per tenere traccia dei problemi software o dei commenti dei clienti. Con tutti i tipi di elemento di lavoro, è possibile personalizzare gli elementi seguenti:

• Aggiungere o rimuovere campi personalizzati
• Aggiungere controlli personalizzati o schede personalizzate all'interno del modulo dell'elemento di lavoro
• Personalizzare gli stati del flusso di lavoro
• Aggiungere regole condizionali
• Scegliere il livello di backlog in cui vengono visualizzati gli elementi di lavoro

Prima di personalizzare il processo, è consigliabile consultare Configurare e personalizzare Azure Boards.

Per personalizzare il processo specifico, vedere Personalizzare un processo di ereditarietà.

Aggiungere o acquisire bug

È possibile definire bug da diversi strumenti di Azure DevOps. Questi includono backlog e schede e strumenti di test.

Suggerimento

Per impostazione predefinita, il campo Titolo è l'unico campo obbligatorio quando si crea un bug. È possibile aggiungere rapidamente bug nello stesso modo in cui si aggiungono storie utente o elementi di backlog del prodotto usando Azure Boards. Se si desidera rendere necessari alcuni campi, aggiungere regole condizionali in base a una modifica dello stato. Per altre informazioni, vedere Aggiungere una regola a un tipo di elemento di lavoro (processo di ereditarietà).

Aggiungere un bug dal backlog o dalla scheda

Se il team ha scelto di gestire i bug con i requisiti, è possibile definire bug dal backlog del prodotto o dalla scheda Kanban. Per altre informazioni, vedere Creare il backlog del prodotto o Iniziare a usare la scheda Kanban.

• Aggiungere un bug dal backlog del prodotto

  

• Aggiungere un bug dal backlog del prodotto

  

Suggerimento

Quando si aggiunge un bug dal backlog del prodotto o dalla scheda Kanban, al bug viene assegnato automaticamente il percorso area predefinito e il percorso di iterazione definiti per il team. Per altre informazioni, vedere Impostazioni predefinite del team a cui fanno riferimento backlog e bacheche.

Aggiungere un bug dal backlog sprint o dalla schermata attività

Se il team ha scelto di gestire i bug con le attività, è possibile definire bug dalla scheda Kanban, dal backlog del prodotto, dal backlog sprint o dalla schermata attività Sprint. Si aggiunge un bug come figlio a un elemento di lavoro del backlog del prodotto.

• Aggiungere un bug figlio collegato dalla scheda Kanban
  Si aggiunge un bug nello stesso modo in cui si aggiunge un'attività a un elemento backlog. Per altre informazioni, vedere Aggiungere attività o elementi figlio come elenchi di controllo.

  

• Aggiungere un bug figlio collegato dal backlog sprint
  Si aggiunge un bug nello stesso modo in cui si aggiunge un'attività a un backlog sprint. Per altre informazioni, vedere Aggiungere attività agli elementi di backlog.

  

Creare un bug da uno strumento di test

I due strumenti di test che è possibile usare per aggiungere bug durante i test includono il portale Web Test Runner e l'estensione Test & Feedback.

• Test Runner: quando si eseguono test manuali, è possibile scegliere Crea bug. Per altre informazioni, vedere Eseguire test manuali.

  

• Estensione Test & Feedback: quando si eseguono test esplorativi, è possibile scegliere Crea bug o Crea attività. Per altre informazioni, vedere Test esplorativi con l'estensione Test & Feedback

Ciclo di vita dei bug e stati del flusso di lavoro

Come per tutti gli altri tipi di elemento di lavoro, il tipo di elemento di lavoro Bug ha un flusso di lavoro ben definito. Ogni flusso di lavoro è costituito da tre o più stati e da un motivo. I motivi specificano il motivo per cui l'elemento è passato da uno stato a un altro. Le immagini seguenti illustrano il flusso di lavoro di bug predefinito definito per i processi Agile, Scrum e CMMI .

Agile	Scrum	CMMI

Per i bug scrum, si modifica lo stato da Commit (simile ad Attivo) a Fine. Per Agile e CMMI, risolvere prima di tutto il bug e selezionare un motivo che indica che il bug è stato corretto. In genere, la persona che ha creato il bug verifica la correzione e aggiorna lo stato da Risolto a Chiuso. Se dopo la risoluzione o la chiusura di un bug è stato trovato più lavoro, è possibile riattivarlo impostando Stato su Commit o Attivo.

Nota

Il tipo di elemento di lavoro del bug del processo Agile in precedenza aveva una regola che riassegnava il bug alla persona che l'ha creata. Questa regola è stata rimossa dal processo di sistema predefinito. È possibile ripristinare questa automazione aggiungendo una regola. Per un processo di ereditarietà, vedere Applicare regole agli stati del flusso di lavoro, Automatizzare la riassegnazione in base alla modifica dello stato.

Verificare una correzione

Per verificare una correzione, uno sviluppatore o un tester tenta di riprodurre il bug e cercare un comportamento più imprevisto. Se necessario, devono riattivare il bug.

Quando si verifica una correzione di bug, è possibile che il bug non sia stato corretto o che si potrebbe non essere d'accordo con la risoluzione. In questo caso, discutere il bug con la persona che l'ha risolta, venire a un accordo e possibilmente riattivare il bug. Se si riattiva un bug, includere i motivi per riattivare il bug nella descrizione del bug.

Chiudere un bug

Si chiude un bug dopo che è stato verificato come corretto. Tuttavia, è anche possibile chiudere un bug per uno dei motivi seguenti. I motivi disponibili per la selezione dipendono dal processo di progetto e dagli stati di transizione dei bug.

Processo Agile:

• Differito: rinviare la correzione di bug fino alla versione successiva del prodotto.
• Correzione: il bug viene verificato come corretto.
• Duplicato: bug tiene traccia di un altro bug attualmente definito. È possibile collegare ogni bug con il tipo di collegamento Duplicato/Duplicato e chiudere uno dei bug.
• Come progettato: la funzionalità funziona come progettato.
• Non è possibile riprodurre: i test dimostrano che il bug non può essere riprodotto.
• Obsoleto: la funzionalità del bug non è più presente nel prodotto.
• Copiato nel backlog: è stata aperta una storia utente per tenere traccia del bug.

Processo scrum:

• Non è un bug: il bug viene verificato che non è un bug.
• Duplicato: bug tiene traccia di un altro bug attualmente definito. È possibile collegare ogni bug con il tipo di collegamento Duplicato/Duplicato e chiudere uno dei bug.
• Rimosso dal backlog: bug verificato che non è un bug. Rimuovere il bug dal backlog.
• Lavoro completato: il bug è stato verificato come corretto.

Processo CMMI:

• Differito: rinviare la correzione di bug fino alla versione successiva del prodotto.
• Duplicato: bug tiene traccia di un altro bug attualmente definito. È possibile collegare ogni bug con il tipo di collegamento Duplicato/Duplicato e chiudere uno dei bug.
• Rifiutato: il bug viene verificato che non è un bug.
• Verificato: il bug viene verificato come corretto.

Suggerimento

Una volta chiuso un bug e la correzione viene rilasciata attivamente nelle distribuzioni, è consigliabile non riaprirla mai a causa della regressione. È invece consigliabile aprire un nuovo bug e collegarsi al bug chiuso meno recente.

È sempre consigliabile descrivere altri dettagli per la chiusura di un bug nel campo Discussione per evitare confusione futura sul motivo per cui il bug è stato chiuso.

Automatizzare la chiusura di bug durante l'unione di richieste pull

Se il team usa un repository Git, è possibile impostare Lo stato in bug collegati e altri elementi di lavoro per chiudere al termine dell'unione delle richieste pull. Per altre informazioni, vedere Impostare lo stato dell'elemento di lavoro nella richiesta pull più avanti in questo articolo.

Elencare e valutare i bug

La maggior parte dei team, qualunque opzione abbia scelto di tenere traccia dei bug, definire una o più query di bug. Con le query è possibile elencare bug attivi, bug non assegnati, bug non aggiornati, tendenze di bug e altro ancora. È quindi possibile aggiungere query e grafici di query ai dashboard del team per monitorare lo stato dei bug e lo stato di avanzamento.

Query di bug

Aprire una query condivisa o usare l'editor di query per creare query di bug utili, ad esempio le opzioni seguenti:

• Bug attivi per priorità (State <> Done o State <> Closed)
• Bug in corso (State = Committed o State = Active)
• Bug da correggere per una versione di destinazione (Tags Contains RTM)
• Bug recenti: bug aperti nelle ultime tre settimane (Created Date > @Today-21)

Dopo aver ottenuto le query di interesse per il team, è possibile creare grafici di stato o di tendenza. È anche possibile aggiungere il grafico creato a un dashboard.

Modalità di valutazione nei risultati della query

Dopo aver iniziato a scrivere codice e testare, è necessario tenere riunioni di valutazione periodiche per esaminare e classificare i bug. In genere, il proprietario del progetto esegue le riunioni di valutazione dei bug. I responsabili del team, gli analisti aziendali e altri stakeholder che possono parlare di rischi specifici del progetto partecipano alle riunioni di valutazione.

Il proprietario del progetto può definire una query condivisa per individuare bug nuovi e riaperti per elencare i bug da valutare.

Dalla pagina dei risultati della query è possibile spostarsi rapidamente verso l'alto e verso il basso all'interno dell'elenco di elementi di lavoro di bug usando le frecce su e giù. Quando si esamina ogni bug, è possibile assegnarlo, aggiungere dettagli o impostare la priorità.

Organizzare e assegnare bug a uno sprint

Se il team tiene traccia dei bug come requisiti, visualizzare l'elenco dei bug attivi dal backlog. Con la funzione di filtro, è possibile concentrarsi esclusivamente sui bug. Dal backlog del prodotto è anche possibile eseguire le attività seguenti:

• Organizzare i bug nel backlog, classificare lo stack rispetto ad altri elementi (la classificazione dello stack è disabilitata quando il filtro è abilitato)
• Assegnare bug a uno sprint dal backlog usando il riquadro Pianificazione
• Bug padre per funzionalità o altri elementi di backlog del portfolio tramite il riquadro Mapping
• Visualizzare l'aggiornamento cumulativo degli elementi di backlog del portfolio.

Se il team tiene traccia dei bug come attività, usare le query gestite per elencare e valutare i bug. Quindi, all'interno di ogni sprint, verranno visualizzati i bug assegnati allo sprint dal backlog sprint o taskboard.

Elementi del pannello delle attività e voci dell'elenco di query

È possibile notare e chiedersi perché gli elementi visualizzati in uno sprint Taskboard possono differire da un elenco di query creato in un backlog sprint corrispondente.

È possibile assegnare attività o bug a un'iterazione, ma non collegarli a un elemento backlog padre. Questi elementi vengono visualizzati nella query creata, ma potrebbero non essere visualizzati nella lavagna stessa. Il sistema esegue la query e quindi applica alcuni processi in background prima di visualizzare gli elementi taskboard.

Questi motivi possono causare la mancata visualizzazione di elementi di lavoro appartenenti alla categoria attività in un backlog sprint o in Taskboard:

• L'attività o il bug non è stato collegato a un elemento backlog padre. Nella pagina del backlog sprint vengono visualizzati solo bug e attività collegate a un elemento backlog del prodotto padre (Scrum), alla storia utente (Agile) o al requisito (CMMI) con un percorso di iterazione impostato sullo sprint.
• L'attività o il bug è un elemento padre di un'altra attività o bug oppure la storia utente è un elemento padre di un'altra storia utente. Se è stata creata una gerarchia di attività, bug o storie utente, vengono visualizzate solo le attività a livello figlio o le storie a livello figlio nella parte inferiore della gerarchia.
• L'elemento padre collegato dell'attività o del bug corrisponde a un elemento backlog definito per un altro team. In alternativa, il percorso dell'area dell'elemento di backlog padre dell'attività o del bug differisce dal percorso dell'area dell'attività o del bug.

Creare test inline collegati a bug

Quando il team tiene traccia dei bug come requisiti, è possibile usare la bacheca Kanban per aggiungere test per verificare le correzioni di bug.

Aggiornare lo stato del bug

È possibile aggiornare lo stato del bug trascinando e rilasciando bug in una nuova colonna in una scheda.

• Se il team tiene traccia dei bug come requisiti, usare la scheda Kanban come illustrato nell'immagine seguente. Per altre informazioni, vedere Introduzione alla scheda Kanban.

  

• Se il team tiene traccia dei bug come attività, usare taskboard. Per altre informazioni, vedere Aggiornare e monitorare il taskboard.

  

Personalizzare la scheda per tenere traccia degli stati intermedi

È possibile aggiungere colonne intermedie per tenere traccia dello stato del bug nella scheda. È anche possibile definire query che filtrano in base allo stato di una colonna scheda. Per altre informazioni, vedere gli articoli seguenti:

• Aggiungere colonne alla scheda Kanban
• Personalizzare uno sprint Taskboard
• Query di modifica della scheda Kanban

Automatizzare la riassegnazione dei bug in base allo stato del flusso di lavoro

Per automatizzare le azioni di selezione, aggiungere regole personalizzate al tipo di elemento di lavoro Bug. Ad esempio, aggiungere una regola come illustrato nell'immagine seguente. Questa regola specifica di riassegnare un bug alla persona che ha aperto il bug una volta risolto. In genere, la persona verifica che il bug sia stato corretto e chiuda il bug. Per altre informazioni, vedere Applicare regole agli stati del flusso di lavoro (processo di ereditarietà).

Impostare lo stato dell'elemento di lavoro nella richiesta pull

Quando si crea una richiesta pull, è possibile impostare il valore di stato degli elementi di lavoro collegati nella descrizione. Seguire la sintassi: {state value}: #ID. Quando si unisce la richiesta pull, il sistema legge la descrizione e aggiorna lo stato dell'elemento di lavoro. Nell'esempio seguente vengono impostati gli elementi di lavoro #300 e #301 su Resolved e #323 e #324 su Closed.

Integrazione in Azure DevOps

Uno dei metodi usati da Azure DevOps per supportare l'integrazione consiste nel collegare oggetti ad altri oggetti. Oltre a collegare elementi di lavoro agli elementi di lavoro, è anche possibile collegare elementi di lavoro ad altri oggetti. Collegamento a oggetti quali compilazioni, versioni, rami, commit e richieste pull, come illustrato nell'immagine seguente.

È possibile aggiungere un collegamento dall'elemento di lavoro o dagli oggetti di compilazione e rilascio.

Collegare elementi di lavoro allo sviluppo

Il controllo Sviluppo supporta il collegamento e la visualizzazione di collegamenti eseguiti a compilazioni, commit Git e richieste pull. In alternativa, quando viene usato un repository TFVC, supporta i collegamenti ai set di modifiche e agli elementi con controllo delle versioni. Se si sceglie il collegamento, viene aperto l'elemento corrispondente in una nuova scheda del browser. Per altre informazioni, vedere Gestire lo sviluppo Git da un elemento di lavoro.

Collegare elementi di lavoro alle versioni

Il controllo Distribuzione supporta collegamenti a e visualizzazione di versioni che contengono gli elementi di lavoro. Ad esempio, l'immagine seguente mostra diverse versioni contenenti collegamenti all'elemento di lavoro corrente. È possibile espandere ogni versione per visualizzare i dettagli su ogni fase. È possibile scegliere il collegamento per ogni versione e fase per aprire la versione o la fase corrispondente. Per altre informazioni, vedere Collegare elementi di lavoro alle distribuzioni.

Collegare elementi di lavoro alle esecuzioni della pipeline

Le pipeline vengono spesso definite per l'esecuzione automatica quando si verifica un nuovo commit in un repository Git. Gli elementi di lavoro associati alle pipeline di commit vengono visualizzati come parte dell'esecuzione della pipeline se si personalizzano le impostazioni della pipeline. Per altre informazioni, vedere Personalizzare la pipeline.

Creare o modificare un elemento di lavoro in caso di errore di compilazione

Se si usano pipeline classiche (non YAML), è possibile creare elementi di lavoro in caso di errore di compilazione. Per altre informazioni, vedere Opzioni di compilazione, Creare un elemento di lavoro in caso di errore.

Monitorare lo stato, le assegnazioni e le tendenze dei bug

È possibile tenere traccia dello stato del bug, delle assegnazioni e delle tendenze usando query che è quindi possibile creare grafici e aggiungere a un dashboard. Ad esempio, di seguito sono riportati due esempi che mostrano le tendenze di bug attive in base allo stato e ai bug attivi per priorità nel tempo.

Per altre informazioni su query, grafici e dashboard; Vedere Informazioni su query gestite e grafici e dashboard.

Usare le visualizzazioni di Analisi e il servizio Analisi per creare report sui bug

Il servizio Analytics è la piattaforma di creazione di report per Azure DevOps, sostituendo la piattaforma precedente basata su SQL Server Reporting Services.

Le viste di analisi forniscono filtri predefiniti per visualizzare gli elementi di lavoro. Per la segnalazione di bug sono supportate quattro visualizzazioni analitiche. È possibile usare queste visualizzazioni come definite o modificarle ulteriormente per creare una visualizzazione personalizzata filtrata.

• Bug - Tutta la cronologia per mese
• Bug - Ultime 26 settimane
• Bug - Ultimi 30 giorni
• Bug - Oggi

Per altre informazioni sull'uso delle visualizzazioni analitiche, vedere Che cosa sono le visualizzazioni di Analisi e Creare un report dei bug attivi in Power BI in base a una visualizzazione analisi personalizzata.

È possibile usare Power BI per creare report più complessi rispetto a quelli che è possibile ottenere da una query. Per altre informazioni, vedere Connessione con Power BI Data Connessione or.

Estensioni del Marketplace

Sono disponibili più estensioni del Marketplace correlate ai bug. Vedere Marketplace per Azure DevOps.

Per altre informazioni sulle estensioni, vedere Estensioni di Azure Boards sviluppate da Microsoft.

Passaggi successivi

Usare i modelli per aggiungere e aggiornare gli elementi di lavoro

Articoli correlati

• Spostare, modificare il tipo o eliminare elementi di lavoro
• Copiare o clonare un elemento di lavoro

Backlog del prodotto e scheda Kanban

• Backlog, portfolio e gestione dei progetti Agile
• Creare il backlog
• Definire caratteristiche ed epiche
• Organizzare il backlog, eseguire il mapping degli elementi di lavoro figlio ai genitori
• Filtrare in modo interattivo backlog, bacheche, query e piani
• Prevedere il backlog del prodotto

Scheda Kanban

• Informazioni su Boards e Kanban
• Guida introduttiva alla scheda Kanban
• Riordinare le schede
• Aggiungere attività o elementi figlio come elenchi di controllo

Backlog sprint e Taskboard

• Scrum e uso delle procedure consigliate per gli sprint
• Assegnare elementi backlog a uno sprint
• Aggiungere attività
• Aggiornare la lavagna delle attività

Integrazione in Azure DevOps

• Collegare storie utente, problemi, bug e altri elementi di lavoro
• Seguire un elemento di lavoro o una richiesta pull
• Configurare numeri di esecuzione o compilazione

Risorse del settore

• Buono e cattivo debito tecnico (e come TDD aiuta) di Henrik Kniberg
• Gestione del debito tecnico registrato da Sven Johann & Eberhard Wolff