Definir, capturar, triar e gerenciar bugs de software nos Painéis do Azure

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

Como você rastreia e gerencia defeitos em seu código? Como você garante que os problemas de software e os comentários dos clientes sejam resolvidos rapidamente para dar suporte a implantações de software de alta qualidade? E como fazer um bom progresso em novos recursos e lidar com sua dívida técnica?

No mínimo, você precisa de uma maneira de capturar seus problemas de software, priorizá-los, atribuí-los a um membro da equipe e acompanhar o progresso. Além disso, você deseja gerenciar seus defeitos de código de maneiras alinhadas com suas práticas ágeis.

Para dar suporte a esses cenários, o Azure Boards fornece um tipo de item de trabalho específico para rastrear defeitos de código chamado Bug. Os itens de trabalho de bug compartilham todos os recursos padrão de outros tipos de item de trabalho com alguns mais. Para obter uma visão geral dos recursos padrão, consulte Acompanhar o trabalho com histórias de usuários, problemas, bugs, recursos e épicos.

Os bugs também fornecem os seguintes recursos adicionais:

• Opções para cada equipe escolher como deseja rastrear bugs
• Ferramentas de teste para capturar bugs
• Integração interna no Azure DevOps para rastrear bugs vinculados a compilações, versões e testes

Nota

Os tipos de item de trabalho de bug não estão disponíveis com o processo Básico. O processo Básico rastreia bugs como Problemas e está disponível quando você cria um novo projeto a partir dos Serviços de DevOps do Azure ou do Azure DevOps Server 2019.1 ou versões posteriores.

Pré-requisitos

• Você deve ser adicionado a um projeto.
• Para exibir ou modificar itens de trabalho, você deve ter suas permissões Exibir itens de trabalho neste nó e Editar itens de trabalho neste nó definidas como Permitir. Por padrão, o grupo de Colaboradores tem esse conjunto de permissões. Para obter mais informações, consulte Definir permissões e acesso para acompanhamento de trabalho.
• Para adicionar novas tags a serem adicionadas a itens de trabalho, você deve ter acesso Básico ou superior e ter as permissões Criar nova definição de tag no nível do projeto definidas como Permitir. Por padrão, o grupo de Colaboradores tem esse conjunto de permissões. Mesmo que a permissão esteja explicitamente definida para um Stakeholder, ele não tem permissão para adicionar novas tags, pois é proibido através de seu nível de acesso. Para obter mais informações, veja Referência rápida sobre o acesso de Interveniente.
• Todos os membros do projeto, mesmo os membros do grupo Leitores , podem enviar e-mails contendo itens de trabalho.

Gorjeta

Para relatar um bug, um usuário deve ter, no mínimo, acesso de partes interessadas e Editar itens de trabalho neste nó definido como Permitir o caminho da área onde eles adicionam o bug. Para obter mais informações, consulte Definir permissões e acesso para controle de trabalho

Tipo de item de trabalho de bug

A imagem a seguir mostra o tipo de item de trabalho Bug para o processo Scrum. O tipo de item de trabalho Bug para processos Agile e CMMI rastreia informações semelhantes. Ele foi projetado para aparecer na lista de pendências do produto junto com os requisitos ou no Quadro de tarefas junto com as tarefas.

Nota

As imagens que você vê do seu portal da Web podem diferir das imagens que você vê neste artigo. Essas diferenças resultam de atualizações feitas em seu aplicativo Web, opções que você ou seu administrador habilitaram e qual processo foi escolhido ao criar seu projeto — Agile, Basic, Scrum ou CMMI. O processo Básico está disponível com o Azure DevOps Server 2019 Update 1 e versões posteriores.

Campos específicos para bugs

O tipo de item de trabalho Bug usa alguns campos específicos do bug. Para capturar o problema inicial e as descobertas em andamento, use os campos descritos na tabela a seguir. Para obter informações sobre campos específicos para o Bug definido para o processo CMMI (Capability Maturity Model Integration), consulte Referência de campo Bugs, problemas e riscos. Para obter informações sobre todos os outros campos, consulte Índice de campo de item de trabalho.

---

Campo, Grupo ou Separador

Utilização

---

Passos para reproduzir
(nome amigável = Repro Steps)

Use para capturar informações suficientes para que outros membros da equipe possam entender completamente o defeito do código. Inclua ações tomadas para localizar ou reproduzir o bug e o comportamento esperado.

---

Informação do Sistema
Encontrado na compilação

Informações sobre o software e a configuração do sistema que são relevantes para o bug e testes a serem aplicados. Os campos Informações do sistema e Encontrado na compilação são preenchidos automaticamente quando você cria um bug por meio de uma ferramenta de teste. Esses campos especificam informações sobre o ambiente de software e compilam onde o bug ocorreu. Para obter mais informações, consulte Testar configurações diferentes.

---

Critérios de aceitação

Forneça os critérios a serem atendidos antes que o bug possa ser fechado. Antes do início do trabalho, descreva os critérios de aceitação do cliente da forma mais clara possível. As equipas devem utilizar estes critérios como base para testes de aceitação e para avaliar se um item foi concluído satisfatoriamente.

---

Integrado no Build

Especifica o nome da compilação que incorpora o código que corrige o bug. Este campo deve ser especificado quando você resolver o bug. Para o Azure DevOps local, para acessar um menu suspenso de todas as compilações que foram executadas, você pode atualizar as FIELD definições de Encontrado na compilação e Integrado na compilação para fazer referência a uma lista global. A lista global é atualizada automaticamente a cada compilação executada. Para obter mais informações, consulte Consulta baseada em campos de integração de compilação e teste.
Para obter informações sobre como definir números de compilação, consulte Opções de formato de número de compilação.

---

Prioridade¹

• 1: O produto requer uma resolução bem-sucedida do item de trabalho antes de ser enviado e resolvido em breve.
• 2: O produto requer uma resolução bem-sucedida do item de trabalho antes de ser enviado, mas não precisa ser resolvido imediatamente.
• 3: A resolução do item de trabalho é opcional com base em recursos, tempo e risco.

---

Gravidade¹

Uma classificação subjetiva do impacto de um bug ou item de trabalho no projeto ou sistema de software. Por exemplo: se um link remoto na interface do usuário — um evento raro — causar uma falha em um aplicativo ou página da Web — uma experiência grave do cliente, você poderá especificar Severidade = 2 - Alta e Prioridade = 3. Os valores permitidos e as diretrizes sugeridas são:

• 1 - Crítico: Deve corrigir. Um defeito que causa o encerramento de um ou mais componentes do sistema ou do sistema completo, ou causa corrupção de dados extensa. E não existem métodos alternativos aceitáveis para alcançar os resultados necessários.
• 2 - Alta: Considere a correção. Um defeito que causa o encerramento de um ou mais componentes do sistema ou do sistema completo, ou causa corrupção de dados extensa. No entanto, existe um método alternativo aceitável para alcançar os resultados necessários.
• 3 - Médio: (Padrão) Um defeito que faz com que o sistema produza resultados incorretos, incompletos ou inconsistentes.
• 4 - Baixo: Um defeito pequeno ou cosmético que tem soluções alternativas aceitáveis para alcançar os resultados necessários.

---

Implementação

O controle Deployment oferece suporte a links e exibição de versões que contêm itens de trabalho. Para usar o controle, você deve habilitar as configurações para a versão. Para obter mais informações, consulte Vincular itens de trabalho a versões mais adiante neste artigo.

---

Desenvolvimento

O controle Development suporta links e exibição de links feitos para objetos de desenvolvimento. Esses objetos incluem solicitações de confirmação e pull do Git ou conjuntos de alterações TFVC e itens versionados. Você pode definir links a partir do item de trabalho ou das confirmações, solicitações pull ou outros objetos de desenvolvimento. Para obter mais informações, consulte Vincular itens de trabalho ao desenvolvimento mais adiante neste artigo.

---

Notas:

1 Para alterar a seleção de menu ou a lista de opções, consulte Personalizar a experiência de acompanhamento de trabalho. O método de personalização depende do modelo de processo usado pelo seu projeto.

Escolha como sua equipe rastreia bugs

Sua equipe pode rastrear bugs como requisitos ou como tarefas. Para apoiar a escolha da equipe, considere os seguintes fatores.

• Tamanho da sua equipa. Equipes menores podem manter uma pegada leve rastreando bugs conforme os requisitos.
• Requisitos da organização para acompanhar o trabalho. Se sua equipe for obrigada a controlar horas, opte por rastrear bugs como tarefas.
• Como a sua equipa organiza o trabalho. Se sua equipe depende da lista de pendências do produto para priorizar o trabalho e adicionar bugs, rastreie os bugs conforme os requisitos.
• Ferramentas que sua equipe deseja usar, como o painel Planejamento, gráfico de velocidade, previsão, rollup e planos de entrega. Rastrear bugs como tarefas impede o uso de várias dessas ferramentas.

A tabela a seguir resume as três opções que as equipes têm para rastrear bugs. Para saber mais e definir a opção para sua equipe, consulte Mostrar bugs em listas de pendências e quadros.

---

Opção

Escolha quando quiser...

---

Rastreie bugs como requisitos

• Priorize bugs (stack rank) juntamente com os requisitos
• Estimar o esforço de bug para previsão
• Atualizar o status do bug no quadro Kanban
• Incluir bugs em gráficos de velocidade e diagramas de fluxo cumulativo
• Pode usar a ferramenta Previsão para dar suporte ao planejamento de sprint
• Pode arrastar e soltar bugs no painel Planejamento para atribuir bugs a um sprint
• Pode ver bugs em planos de entrega

Nota

• Os bugs são atribuídos à Categoria de Requisitos

---

Rastreie bugs como tarefas

• Estimar o trabalho para bugs semelhantes a tarefas
• Atualizar o status do bug nos quadros de tarefas do sprint
• Vincular bugs a requisitos como itens filho
• Pode arrastar e soltar bugs no painel Planejamento para atribuir bugs a um sprint

Nota

• Os bugs são atribuídos à Categoria de Tarefa
• User Stories (Agile), Product Backlog Items (Scrum) ou Requirements (CMMI) são o tipo de item de trabalho pai natural para Bugs
• Os bugs não serão visíveis nos Planos de Entrega

---

Os bugs não aparecem em listas de pendências ou quadros

• Gerenciar bugs usando consultas

Nota

• Os bugs estão associados à Categoria de Bugs e não aparecerão em listas de pendências ou placas
• Os bugs não serão visíveis em Listas de Pendências, Painéis, Listas de Pendências da Sprint, Quadros de Tarefas ou Planos de Entrega
• Não é possível arrastar e soltar bugs no painel Planejamento para atribuir bugs a um sprint

---

Personalizar tipo de item de trabalho

Você pode personalizar o Bug e outros tipos de item de trabalho. Ou crie tipos personalizados para acompanhar problemas de software ou comentários de clientes. Com todos os tipos de item de trabalho, você pode personalizar os seguintes elementos:

• Adicionar ou remover campos personalizados
• Adicionar controles personalizados ou guias personalizadas dentro do formulário de item de trabalho
• Personalizar os estados do fluxo de trabalho
• Adicionar regras condicionais
• Escolha o nível de lista de pendências em que os itens de trabalho aparecem

Antes de personalizar seu processo, recomendamos que você revise Configurar e personalizar os Painéis do Azure.

Para personalizar seu processo específico, consulte Personalizar um processo de herança.

Adicionar ou capturar bugs

Você pode definir bugs de várias ferramentas diferentes do Azure DevOps. Estes incluem listas de pendências e quadros e ferramentas de teste.

Gorjeta

Por padrão, o campo Título é o único campo obrigatório ao criar um bug. Você pode adicionar bugs rapidamente da mesma forma que adiciona histórias de usuários ou itens de lista de pendências de produtos usando os Painéis do Azure. Se você quiser tornar alguns campos obrigatórios, faça isso adicionando regras condicionais com base em uma alteração de estado. Para obter mais informações, consulte Adicionar uma regra a um tipo de item de trabalho (Processo de herança).

Adicione um bug da sua lista de pendências ou quadro

Se sua equipe optou por gerenciar bugs com requisitos, você pode definir bugs a partir de sua lista de pendências de produtos ou quadro Kanban. Para obter mais informações, consulte Criar sua lista de pendências de produtos ou Começar a usar seu quadro Kanban.

• Adicionar um bug da lista de pendências do produto

  

• Adicionar um bug da lista de pendências do produto

  

Gorjeta

Quando você adiciona um bug da sua lista de pendências do produto ou do quadro Kanban, o bug recebe automaticamente o Caminho de Área e o Caminho de Iteração padrão definidos para a equipe. Para obter mais informações, consulte Padrões de equipe referenciados por listas de pendências e painéis.

Adicionar um bug da sua lista de pendências de sprint ou do Taskboard

Se sua equipe optou por gerenciar bugs com tarefas, você pode definir bugs a partir do seu quadro Kanban, lista de pendências de produtos, lista de pendências da Sprint ou quadro de tarefas da Sprint. Você adiciona um bug como filho a um item de trabalho da lista de pendências do produto.

• Adicionar um bug filho vinculado do quadro Kanban
  Você adiciona um bug da mesma forma que adiciona uma tarefa a um item de lista de pendências. Para obter mais informações, consulte Adicionar tarefas ou itens filho como listas de verificação.

  

• Adicionar um bug filho vinculado a partir da lista de pendências da Sprint
  Você adiciona um bug da mesma forma que adiciona uma tarefa a uma lista de pendências do Sprint. Para obter mais informações, consulte Adicionar tarefas a itens da lista de pendências.

  

Criar um bug a partir de uma ferramenta de teste

As duas ferramentas de teste que você pode usar para adicionar bugs durante o teste incluem o Test Runner do portal da Web e a extensão Test & Feedback.

• Test Runner: Ao executar testes manuais, você pode optar por Criar bug. Para obter mais informações, consulte Executar testes manuais.

  

• Test & Feedback extension: Ao executar testes exploratórios, você pode optar por Criar bug ou Criar tarefa. Para obter mais informações, consulte Teste exploratório com a extensão Test & Feedback

Ciclo de vida do bug e estados do fluxo de trabalho

Como em todos os outros tipos de item de trabalho, o tipo de item de trabalho Bug tem um fluxo de trabalho bem definido. Cada fluxo de trabalho consiste em três ou mais Estados e um Motivo. As razões especificam por que o item transitou de um Estado para outro. As imagens a seguir ilustram o fluxo de trabalho de bug padrão definido para os processos Agile, Scrum e CMMI.

Ágil	Scrum	CMMI

Para bugs do Scrum, você altera o Estado de Comprometido (semelhante ao Ativo) para Concluído. Para Agile e CMMI, você primeiro resolve o bug e seleciona um motivo que indica que o bug foi corrigido. Normalmente, a pessoa que criou o bug verifica a correção e atualiza o Estado de Resolvido para Fechado. Se mais trabalho tiver sido encontrado depois que um bug foi resolvido ou fechado, você pode reativá-lo definindo o Estado como Confirmado ou Ativo.

Nota

O tipo de item de trabalho de bug do processo Agile anteriormente tinha uma regra que reatribuía o bug à pessoa que o criou. Esta regra foi removida do processo padrão do sistema. Você pode restabelecer essa automação adicionando uma regra. Para um processo de herança, consulte Aplicar regras a estados de fluxo de trabalho, Automatizar a reatribuição com base na alteração de estado.

Verificar uma correção

Para verificar uma correção, um desenvolvedor ou testador tenta reproduzir o bug e procurar um comportamento mais inesperado. Se necessário, eles devem reativar o bug.

Ao verificar uma correção de bug, você pode achar que o bug não foi corrigido ou você pode discordar da resolução. Neste caso, discuta o bug com a pessoa que o resolveu, chegue a um acordo e, possivelmente, reative o bug. Se você reativar um bug, inclua os motivos para reativá-lo na descrição do bug.

Fechar um bug

Você fecha um bug depois que ele é verificado como corrigido. No entanto, você também pode fechar um bug por um dos seguintes motivos. Os motivos disponíveis para selecionar dependem do processo do projeto e dos estados de transição do bug.

Processo ágil:

• Adiado: adie a correção de bugs até o próximo lançamento do produto.
• Corrigido: O bug é verificado como corrigido.
• Duplicado: Bug rastreia outro bug atualmente definido. Você pode vincular cada bug com o tipo de link Duplicar/Duplicar e fechar um dos bugs.
• Conforme projetado: O recurso funciona como projetado.
• Não é possível reproduzir: os testes provam que o bug não pode ser reproduzido.
• Obsoleto: O recurso do bug não está mais no produto.
• Copiado para Backlog: Uma história de usuário foi aberta para rastrear o bug.

Processo Scrum:

• Não é um bug: Bug é verificado que não é um bug.
• Duplicado: Bug rastreia outro bug atualmente definido. Você pode vincular cada bug com o tipo de link Duplicar/Duplicar e fechar um dos bugs.
• Removido da lista de pendências: Bug é verificado que não é um bug. Remova o bug da lista de pendências.
• Trabalho concluído: Bug foi verificado como corrigido.

Processo CMMI:

• Adiado: adie a correção de bugs até o próximo lançamento do produto.
• Duplicado: Bug rastreia outro bug atualmente definido. Você pode vincular cada bug com o tipo de link Duplicar/Duplicar e fechar um dos bugs.
• Rejeitado: Bug é verificado que não é um bug.
• Verificado: O bug foi verificado como corrigido.

Gorjeta

Uma vez que um bug tenha sido fechado e a correção seja lançada ativamente em implantações, a prática recomendada é nunca reabri-lo devido à regressão. Em vez disso, você deve considerar abrir um novo bug e vincular ao bug mais antigo e fechado.

É sempre uma boa ideia descrever mais detalhes para fechar um bug no campo Discussão para evitar confusão futura sobre o motivo pelo qual o bug foi fechado.

Automatize o fechamento de bugs ao mesclar solicitações pull

Se sua equipe usa um repositório Git, você pode definir o Estado em bugs vinculados e outros itens de trabalho para fechar após a mesclagem bem-sucedida de solicitações pull. Para obter mais informações, consulte Definir o estado do item de trabalho na solicitação pull mais adiante neste artigo.

Lista e triagem de bugs

A maioria das equipes, qualquer que seja a opção escolhida para rastrear bugs, define uma ou mais consultas de bugs. Com consultas, você pode listar bugs ativos, bugs não atribuídos, bugs obsoletos, tendências de bugs e muito mais. Em seguida, você pode adicionar consultas e gráficos de consulta aos painéis da sua equipe para monitorar o status e o progresso do bug.

Consultas de bugs

Abra uma consulta compartilhada ou use o editor de consultas para criar consultas de bugs úteis, como as seguintes opções:

• Bugs ativos por prioridade (State <> Done ou State <> Closed)
• Bugs em andamento (State = Committed ou State = Active)
• Bugs a serem corrigidos para uma versão de destino (Tags Contains RTM)
• Bugs recentes - bugs abertos nas últimas três semanas (Created Date > @Today-21)

Depois de ter as consultas de interesse para sua equipe, você pode criar gráficos de status ou tendências. Você também pode adicionar o gráfico criado a um painel.

Modo de triagem nos resultados da consulta

Depois de começar a codificar e testar, convém realizar reuniões periódicas de triagem para revisar e classificar seus bugs. Normalmente, o proprietário do projeto executa as reuniões de triagem de bugs. Líderes de equipe, analistas de negócios e outras partes interessadas que podem falar sobre riscos específicos do projeto participam das reuniões de triagem.

O proprietário do projeto pode definir uma consulta compartilhada para bugs novos e reabertos para listar bugs a serem triados.

Na página de resultados da consulta, você pode mover rapidamente para cima e para baixo dentro da lista de itens de trabalho de bug usando as setas para cima e para baixo. Ao analisar cada bug, você pode atribuí-lo, adicionar detalhes ou definir prioridade.

Organizar e atribuir bugs a um sprint

Se sua equipe rastrear bugs como requisitos, veja a lista de bugs ativos da sua lista de pendências. Com a função de filtro, você pode se concentrar apenas em bugs. Na lista de pendências do produto, você também pode executar as seguintes tarefas:

• Organize bugs em sua lista de pendências, empilhar a classificação em relação a outros itens (a classificação de pilha é desativada quando a filtragem está ativada)
• Atribuir bugs a um sprint a partir da sua lista de pendências usando o painel Planejamento
• Bugs pai para Recursos ou outros itens da lista de pendências do portfólio usando o painel Mapeamento
• Visualize o acúmulo de trabalho para itens da lista de pendências do portfólio.

Se sua equipe rastrear bugs como tarefas, use consultas gerenciadas para listar e triar bugs. Em seguida, dentro de cada sprint, você verá os bugs atribuídos ao sprint na lista de pendências ou no quadro de tarefas do Sprint.

Itens do quadro de tarefas versus itens da lista de consultas

Você pode notar e se perguntar por que os itens mostrados em um quadro de tarefas de sprint podem diferir de uma lista de consulta criada em uma lista de pendências de sprint correspondente.

É possível atribuir tarefas ou bugs a uma iteração, mas não vinculá-los a um item de lista de pendências pai. Esses itens aparecem na consulta criada, mas podem não aparecer no próprio Taskboard. O sistema executa a consulta e, em seguida, aplica alguns processos em segundo plano antes de exibir itens do quadro de tarefas.

Esses motivos podem fazer com que os itens de trabalho que pertencem à Categoria de Tarefa não apareçam em uma lista de pendências de sprint ou no Quadro de Tarefas:

• A tarefa ou bug não foi vinculado a um item de lista de pendências pai. Somente bugs e tarefas que você vinculou a um item de lista de pendências do produto pai (Scrum), história de usuário (Agile) ou requisito (CMMI) com um caminho de iteração definido para o sprint aparecem na página de lista de pendências do sprint.
• A tarefa ou bug é pai de outra tarefa ou bug, ou a história de usuário é pai de outra história de usuário. Se você criou uma hierarquia de tarefas, bugs ou histórias de usuário, somente as tarefas de nível filho ou as histórias de nível infantil na parte inferior da hierarquia serão exibidas.
• O pai vinculado da tarefa ou do bug corresponde a um item de lista de pendências definido para outra equipe. Ou, o caminho da área do item de lista de pendências pai da tarefa ou do bug difere do caminho da área da tarefa ou do bug.

Criar testes embutidos vinculados a bugs

Quando sua equipe rastreia bugs como requisitos, você pode usar o quadro Kanban para adicionar testes para verificar correções de bugs.

Atualizar status do bug

Você pode atualizar o status do bug arrastando e soltando bugs em uma nova coluna em um quadro.

• Se sua equipe rastreia bugs como requisitos, você usa o quadro Kanban, conforme mostrado na imagem a seguir. Para obter mais informações, consulte Introdução ao seu quadro Kanban.

  

• Se sua equipe rastrear bugs como tarefas, use o Quadro de tarefas. Para obter mais informações, consulte Atualizar e monitorar seu painel de tarefas.

  

Personalize sua placa para rastrear estados intermediários

Você pode adicionar colunas intermediárias para acompanhar o status do bug no quadro. Você também pode definir consultas que filtram com base no status de uma Coluna do painel. Para obter mais informações, consulte os seguintes artigos que podem estar em inglês:

• Adicionar colunas ao seu quadro Kanban
• Personalizar um quadro de tarefas de sprint
• Consultas de alteração do quadro Kanban

Automatize a reatribuição de bugs com base no estado do fluxo de trabalho

Para automatizar ações selecionadas, adicione regras personalizadas ao seu tipo de item de trabalho de bug. Por exemplo, adicione uma regra como mostrado na imagem a seguir. Esta regra especifica para reatribuir um bug à pessoa que abriu o bug assim que ele for resolvido. Normalmente, essa pessoa verifica se o bug foi corrigido e fecha o bug. Para obter mais informações, consulte Aplicar regras a estados de fluxo de trabalho (processo de herança).

Definir o estado do item de trabalho na solicitação pull

Ao criar uma solicitação pull, você pode definir o valor de estado dos itens de trabalho vinculados na descrição. Siga a sintaxe: {state value}: #ID. Quando você mescla a solicitação pull, o sistema lê a descrição e atualiza o estado do item de trabalho. No exemplo a seguir, definimos os itens de trabalho #300 e #301 como Resolvido e #323 e #324 como Fechado.

Integração no Azure DevOps

Um dos métodos usados pelo Azure DevOps para dar suporte à integração é vincular objetos a outros objetos. Além de vincular itens de trabalho a itens de trabalho, você também pode vincular itens de trabalho a outros objetos. Link para objetos como compilações, liberações, ramificações, confirmações e solicitações pull, conforme ilustrado na imagem a seguir.

Você pode adicionar um link do item de trabalho ou dos objetos build e release.

Vincular itens de trabalho ao desenvolvimento

O controle de desenvolvimento suporta a vinculação e exibição de links feitos para compilações, confirmações do Git e solicitações pull. Ou, quando um repositório TFVC é usado, ele suporta links para conjuntos de alterações e itens versionados. Escolher o link abre o item correspondente em uma nova guia do navegador. Para obter mais informações, consulte Impulsionar o desenvolvimento do Git a partir de um item de trabalho.

Vincular itens de trabalho a versões

O controle de implantação oferece suporte a links e exibição de versões que contêm os itens de trabalho. Por exemplo, a imagem a seguir mostra várias versões que contêm links para o item de trabalho atual. Você pode expandir cada versão para ver detalhes sobre cada etapa. Você pode escolher o link para cada versão e estágio para abrir a versão ou estágio correspondente. Para obter mais informações, consulte Vincular itens de trabalho a implantações.

Vincular itens de trabalho a execuções de pipeline

Os pipelines geralmente são definidos para serem executados automaticamente quando ocorre uma nova confirmação em um repositório Git. Os itens de trabalho associados aos pipelines de confirmação aparecem como parte da execução do pipeline se você personalizar as configurações do pipeline. Para obter mais informações, consulte Personalizar seu pipeline.

Criar ou editar um item de trabalho em caso de falha de compilação

Se você usar pipelines clássicos (não YAML), poderá criar itens de trabalho em uma falha de compilação. Para obter mais informações, consulte Opções de compilação, Criar um item de trabalho em caso de falha.

Monitore o status de bugs, atribuições e tendências

Você pode acompanhar o status do bug, atribuições e tendências usando consultas que você pode criar gráficos e adicionar a um painel. Por exemplo, aqui estão dois exemplos mostrando tendências de bugs ativos por Estado e Bugs Ativos por Prioridade ao longo do tempo.

Para saber mais sobre consultas, gráficos e painéis; consulte Sobre consultasgerenciadas, gráficos e painéis.

Usar as visualizações do Google Analytics e o serviço do Google Analytics para criar relatórios de bugs

O serviço Analytics é a plataforma de relatórios para o Azure DevOps, substituindo a plataforma anterior baseada no SQL Server Reporting Services.

As visualizações do Google Analytics fornecem filtros pré-criados para exibir itens de trabalho. Quatro visualizações analíticas são suportadas para relatórios de bugs. Você pode usar esses modos de exibição conforme definido ou editá-los ainda mais para criar um modo de exibição personalizado e filtrado.

• Bugs - Todo o histórico por mês
• Bugs - Últimas 26 semanas
• Bugs - Últimos 30 dias
• Bugs - Hoje

Para saber mais sobre como usar modos de exibição analíticos, consulte O que são modos de exibição do Google Analytics e Criar um relatório de bugs ativos no Power BI com base em um modo de exibição personalizado do Google Analytics.

Você pode usar o Power BI para criar relatórios mais complexos do que o que você pode obter de uma consulta. Para obter mais informações, consulte Conectar-se com o Power BI Data Connector.

Extensões do Marketplace

Existem várias extensões do Marketplace relacionadas a bugs. Consulte Marketplace para Azure DevOps.

Para obter mais informações sobre extensões, consulte Extensões do Azure Boards desenvolvidas pela Microsoft.

Próximos passos

Usar modelos para adicionar e atualizar itens de trabalho

Artigos relacionados

• Mover, alterar o tipo ou excluir itens de trabalho
• Copiar ou clonar um item de trabalho

Backlog de produtos e quadro Kanban

• Backlogs, portfólios e gerenciamento ágil de projetos
• Crie a sua lista de pendências
• Definir características e épicos
• Organize sua lista de pendências, mapeie itens de trabalho infantil para os pais
• Filtre interativamente listas de pendências, quadros, consultas e planos
• Preveja a lista de pendências do seu produto

Quadro Kanban

• Sobre Boards e Kanban
• Guia de início rápido do quadro Kanban
• Reordenar cartões
• Adicionar tarefas ou itens filho como listas de verificação

Sprint backlog e Taskboard

• Scrum e trabalhar com as melhores práticas de sprints
• Atribuir itens da lista de pendências a um sprint
• Adicionar tarefas
• Atualizar o quadro de tarefas

Integração no Azure DevOps

• Vincular histórias de usuários, problemas, bugs e outros itens de trabalho
• Seguir um item de trabalho ou pull request
• Configurar números de execução ou compilação

Recursos da indústria

• Dívida Técnica Boa e Má (e como o TDD ajuda) por Henrik Kniberg
• Gestão da Dívida Técnica postado por Sven Johann & Eberhard Wolff