Compartilhar via

Definir, capturar, fazer a triagem e gerenciar bugs de software no Azure Boards

  • Artigo

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

Como você rastreia e gerencia defeitos no código? Como garantir que problemas de software e comentários de clientes sejam resolvidos rapidamente para dar suporte a implantações de software de alta qualidade? Como conquistar avanços em novos recursos e lidar com sua dívida técnica?

No mínimo, você precisa ter uma maneira de capturar seus problemas de software, priorizá-los, atribuí-los a um membro da equipe e acompanhar o progresso. Você deseja gerenciar os defeitos de código de maneiras alinhadas às suas práticas Agile.

Para oferecer suporte a esses cenários, o Azure Boards fornece um tipo de item de trabalho específico, chamado Bug, para rastrear defeitos de código. Os itens de trabalho de bug compartilham todos os recursos padrão de outros tipos de item de trabalho, além de mais alguns. Para obter uma visão geral dos recursos padrão, consulte Sobre itens de trabalho e tipos de item de trabalho.

Os bugs também fornecem os seguintes recursos:

  • 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 builds, versões e testes

Observação

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 fica disponível quando você cria um projeto do Azure DevOps Services ou do Azure DevOps Server 2019.1 ou versões posteriores.

Pré-requisitos

  • Acesso ao projeto: ser adicionado a um projeto.

  • Permissões:

    • Ter as permissões Exibir itens de trabalho neste nó e Editar itens de trabalho neste nó definidas como Permitir. Por padrão, o grupo Colaboradores tem essas permissões. Para obter mais informações, consulte Definir permissões de acompanhamento de trabalho.

    • Para adicionar novas marcações, é necessário o acesso Básico ou superior e a permissão de nível de projeto Criar nova definição de marcação definida como Permitir. Por padrão, o grupo Colaboradores tem essa permissão.

      Observação

      Stakeholders não podem adicionar novas marcações, mesmo que a permissão seja definida explicitamente, devido ao seu nível de acesso. Para mais informações, veja Referência rápida de acesso das partes interessadas.

  • Enviar itens de trabalho por email: todos os membros do projeto, incluindo aqueles no grupo Leitores , podem enviar emails contendo itens de trabalho.

Dica

Para relatar um bug, um usuário deve ter, pelo menos, acesso ao Stakeholder. Um usuário deve ter a permissão Editar itens de trabalho neste nó definida como Permitir para o Caminho da Área em que adiciona o bug. Para obter mais informações, consulte Definir permissões de acompanhamento de trabalho

Tipo de item de trabalho Bug

A imagem a seguir mostra o tipo de item de trabalho Bug para o processo de Scrum. O tipo de item de trabalho Bug para processos Agile e CMMI (Integração de Modelos de Maturidade de Capacidade) rastreia informações semelhantes. Ele aparece na Lista de Pendências do Produto junto com os requisitos ou no Quadro de Tarefas junto com as tarefas.

Observação

As imagens que exibidas no portal da Web podem ser diferentes das apresentadas neste artigo. Essas diferenças resultam de atualizações feitas em seu aplicativo Web, opções que você ou o administrador habilitou e qual processo foi escolhido ao criar o projeto: Agile, Básico, Scrum ou CMMI. O processo Básico está disponível no Azure DevOps Server 2019 Atualização 1 e em versões posteriores.

A captura de tela mostra um formulário do tipo de item de trabalho Bug para o processo Scrum no Azure DevOps Server 2020 e no serviço de nuvem.

A captura de tela mostra um formulário do tipo de item de trabalho Bug para o processo Scrum no Azure DevOps Server 2019.

Campos específicos para bugs

O tipo de item de trabalho Bug usa alguns campos específicos relacionados a bugs. Para capturar o problema inicial e descobertas em andamento, use os campos descritos na tabela a seguir. Para obter informações sobre campos específicos ao Bug definidos para o processo CMMI (Integração do Modelo de Maturidade de Capacidade), confira Referência de campos de bugs, problemas e riscos. Para saber mais sobre todos os outros campos, confira Índice de campos de item de trabalho.

Campo, grupo ou guia

Uso

Etapas para reproduzir (nome amigável = etapas de reprodução)

Use para capturar informações suficientes para que outros membros da equipe possam entender completamente o defeito do código. Inclui ações executadas para localizar ou reproduzir o bug, bem como o comportamento esperado.

Informações do sistemaEncontrado no Build

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

Critérios de aceitação

Informe os critérios a serem atendidos para que o bug possa ser fechado. Antes que o trabalho seja iniciado, descreva os critérios de aceitação do cliente da maneira mais clara possível. As equipes devem usar esses critérios como base para os testes de aceitação e para avaliar se um item é concluído de forma satisfatória.

Integrado no build

Especifica o nome do build que incorpora o código que corrige o bug. Esse campo deverá ser especificado quando você resolver o bug.

No Azure DevOps local, para acessar um menu suspenso de todos os builds executados, você pode atualizar as definições de FIELD para Encontrado no Build e Integrado no Build para fazer referência a uma lista global. A lista global é automaticamente atualizada com cada compilação executada. Para obter mais informações, consulte Consulta com base nos campos de integração de build e teste.

Para obter informações sobre como definir números de build, consulte Configuração de pipelines clássicos.

Prioridade1

  • 1: o produto requer uma resolução bem-sucedida do item de trabalho antes de ser enviado, a ser 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 é opcional, com base em recursos, tempo e risco.

Gravidade1

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

  • 1 – Crítico: precisa ser corrigido. Um defeito que causa o encerramento de um ou mais componentes do sistema ou do sistema inteiro ou que causa corrupção extensiva de dados. Não há métodos alternativos aceitáveis para alcançar os resultados necessários.
  • 2 – Alta: considere corrigir. Um defeito que causa o encerramento de um ou mais componentes do sistema ou do sistema inteiro ou que causa corrupção extensiva de dados. 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 secundário ou cosmético que tem soluções alternativas aceitáveis para alcançar os resultados necessários.

Implantação

O controle Implantação dá suporte a links para versões que contêm itens de trabalho e à exibição dessas versões. Para usar o controle, você precisa habilitar as configurações para a versão. Para obter mais informações, consulte Link de itens de trabalho para versões posteriormente neste artigo.

Desenvolvimento

O controle Desenvolvimento dá suporte a links e à exibição de links para objetos de desenvolvimento. Esses objetos incluem PRs e commits do Git, ou conjuntos de alterações e itens com Controle de Versão do Team Foundation. Você pode definir links do item de trabalho ou dos commits, das PRs e de outros objetos de desenvolvimento. Para obter mais informações, consulte Vincular itens de trabalho ao desenvolvimento mais adiante neste artigo.

Observações

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

Escolher como a equipe rastreia bugs

A equipe pode rastrear bugs como requisitos ou como tarefas. Para dar suporte à escolha da equipe, considere os fatores a seguir.

  • Tamanho da equipe. Equipes menores podem manter um volume menor rastreando bugs como requisitos.
  • Requisitos da organização com relação a como rastrear o trabalho. Se a equipe precisar rastrear as horas, opte por rastrear bugs como tarefas.
  • Organização do trabalho da sua equipe. Se a equipe depende da Lista de Pendências do Produto para priorizar o trabalho e adicionar bugs, rastreie os bugs como requisitos.
  • Ferramentas que a equipe deseja usar, como o painel Planejamento, o gráfico de velocidade, a previsão, os itens acumulados e os 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, confira Mostrar bugs em listas de pendências e quadros.

Opção

Escolha quando desejar...

Rastrear bugs como requisitos

Observação

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

Rastrear bugs como Tarefas

  • Estimar o trabalho para bugs de modo semelhantes às tarefas
  • Atualizar o status dos bugs em Quadros de tarefas de sprint
  • Vincular bugs a requisitos como itens filho
  • Arrastar bugs para o painel Planejamento e atribuir bugs a um sprint

Observação

  • Os bugs são atribuídos à Categoria de Tarefa
  • Histórias de Usuário (Agile), Itens da Lista de Pendências do Produto (Scrum) ou Requisitos (CMMI) são o tipo de item de trabalho pai natural para os Bugs
  • Os bugs não são visíveis nos Planos de Entrega

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

  • Gerenciar bugs usando consultas

Observação

  • Os bugs são associados à Categoria de Bugs e não aparecem em listas de pendências nem quadros
  • Os bugs não são em Listas de Pendências, Quadros, Listas de Pendências de Sprint, Quadros de Tarefas nem Planos de Entrega
  • Você não pode arrastar bugs para o 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 rastrear problemas de software ou comentários do cliente. Para todos os tipos de item de trabalho, você pode personalizar os seguintes elementos:

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

Antes de personalizar seu processo, recomendamos que você consulte Sobre a configuração e personalização do Azure Boards.

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

Para personalizar seu processo específico, confira Personalizar um processo de herança ou Personalizar o modelo de processo XML local.

Adicionar ou capturar bugs

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

Dica

Por padrão, o campo Título é o único obrigatório quando você cria um bug. Você pode adicionar bugs da mesma forma como adiciona histórias de usuário ou itens da lista de pendências do produto usando o Azure Boards. Você pode tornar alguns campos necessários 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.

Adicionar um bug da lista de pendências ou do quadro

Se a equipe optar por gerenciar bugs com requisitos, você poderá definir bugs a partir da lista de pendências do produto ou do quadro. Para obter mais informações, consulte Criar sua lista de pendências do produto ou Usar seu quadro.

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

    A captura de tela mostra a adição de um bug da lista de pendências do produto.

  • Adicionar um bug do quadro

    A captura de tela mostra a adição de um bug do quadro.

Dica

Quando você adiciona um bug da lista de pendências do produto ou do quadro, 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 da equipe referenciados por listas de pendências e placas.

Adicionar um bug do quadro de tarefas ou da lista de pendências do sprint

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

Criar um bug usando uma ferramenta de teste

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

Ciclo de vida e estados de fluxo de trabalho do bug

Assim como acontece com 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 é composto por três ou mais Estados e um Motivo. Os motivos especificam por que o item fez a transição 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.

Agile Scrum CMMI
O diagrama mostra os estados de fluxo de trabalho de bug no modelo de processo Agile. O diagrama mostra os estados de fluxo de trabalho de bug no modelo de processo Scrum. O diagrama mostra os estados de fluxo de trabalho de bug no modelo de processo CMMI.

Para bugs do Scrum, você altera o Estado de Confirmado (semelhante a Ativo) para Concluído. Para os processos Agile e CMMI, primeiro você resolve o bug e seleciona um motivo que indique 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 você encontrar mais trabalho após resolver ou fechar um bug, reative-o definindo o Estado como Confirmado ou Ativo.

Observação

O tipo de item de trabalho de bug do processo Agile tinha uma regra que reatribuia o bug à pessoa que o criou. Essa regra foi removida do processo do sistema padrão. É possível restabelecer essa automação adicionando uma regra. Para um processo de herança, consulte 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 buscar mais comportamentos inesperados. Se necessário, ele deve reativar o bug.

Ao verificar uma correção de bug, você pode descobrir que o bug não foi corrigido ou pode discordar da resolução. Nesse 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 quando um membro da equipe verifica que ele foi corrigido. No entanto, você também pode fechar um bug por um dos motivos a seguir. Os motivos disponíveis dependem do processo do projeto e dos estados de transição do bug.

Processo Agile:

  • Adiado: adiar a correção do bug até a próxima versão do produto.
  • Corrigido: o bug é verificado como corrigido.
  • Duplicado: o bug rastreia outro bug definido no momento. Você pode vincular cada bug com o tipo de link Duplicado/Duplicado de e fechar um dos bugs.
  • Como projetado: o recurso funciona conforme 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 a lista de pendências: uma História de Usuário foi aberta para rastrear o bug.

Processo Scrum:

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

Processo CMMI:

  • Adiado: adiar a correção do bug até a próxima versão do produto.
  • Duplicado: o bug rastreia outro bug definido no momento. Você pode vincular cada bug com o tipo de link Duplicado/Duplicado de e fechar um dos bugs.
  • Rejeitado: verificou-se que o bug não é um bug.
  • Verificado: o bug é verificado como corrigido.

Dica

Depois que um bug for fechado e a correção ser lançada ativamente em implantações, a prática recomendada é nunca reabri-lo devido à regressão. Em vez disso, considere abrir um novo bug e vinculá-lo ao bug fechado mais antigo.

Sempre é uma boa ideia descrever mais detalhes para fechar um bug no campo Discussão, a fim de evitar confusão futura sobre o motivo para o bug ter sido fechado.

Automatizar o fechamento de bugs ao mesclar PRs

Se a equipe usa um repositório Git, você pode definir o Estado em bugs vinculados e em outros itens de trabalho para fechar após a mesclagem bem-sucedida de PRs. Para saber mais, confira Definir o estado do item de trabalho na PR mais adiante neste artigo.

Listar e fazer a triagem de bugs

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

Consultas de bug

Abra uma consulta compartilhada ou use o editor de consultas para criar consultas de bug ú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, como bugs abertos nas últimas três semanas (Created Date > @Today-21)

Quando você tiver as consultas de interesse de sua equipe, poderá criar gráficos de tendências ou status. 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, faça reuniões de triagem periódicas para analisar 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 outros stakeholders 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 a fim de listar os bugs que deverão passar pela triagem.

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

Captura de tela dos Resultados da Consulta, Bugs Ativos e modo de Triagem no painel direito.

Organizar e atribuir bugs a um sprint

Se a equipe rastrear bugs como requisitos, exiba a lista de bugs ativos da lista de pendências. Com a função de filtro, você pode se concentrar apenas nos bugs. Na Lista de Pendências do Produto, você também pode realizar as seguintes tarefas:

Se a equipe rastreia bugs como tarefas, use consultas gerenciadas para listar e fazer a triagem de bugs. Em cada sprint, você vê os bugs atribuídos ao sprint na lista de pendências do Sprint ou no Quadro de Tarefas.

Itens do quadro de tarefas versus itens da lista de consultas

Você pode observar e se perguntar por que os itens mostrados no Quadro de Tarefas de um sprint podem ser diferentes de uma lista de consultas criada na lista de pendências do sprint correspondente.

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

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

  • A tarefa ou bug não está vinculado a um item de lista de pendências pai. Apenas bugs e tarefas são vinculados a um item da lista de pendências de produto (Scrum), História de Usuário (Agile) ou requisito (CMMI) pai cujo caminho de iteração estiver definido para o sprint aparecerão na página da 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ê criar uma hierarquia de tarefas, bugs ou histórias de usuário, apenas tarefas no nível filho ou histórias no nível filho no fim da hierarquia serão exibidas. Para obter mais informações, consulte Solucionar problemas de reordenação e aninhamento.
  • O pai vinculado da tarefa ou bug corresponde a um item da lista de pendências definido para outra equipe. Ou o caminho da área do item da lista de pendências pai da tarefa ou bug difere do caminho da área da tarefa ou bug.

Criar testes embutidos vinculados a bugs

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

Captura de tela do quadro, três colunas mostrando testes embutidos adicionados e vinculados a bugs.

Atualizar o status dos bugs

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

Personalizar o quadro para rastrear estados intermediários

Você pode adicionar colunas intermediárias para rastrear o status do bug no quadro. Você também pode definir consultas que são filtradas com base no status de uma Coluna do Quadro. Para obter mais informações, consulte os seguintes artigos:

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

Para automatizar ações selecionadas, adicione regras personalizadas ao tipo de item de trabalho Bug. Por exemplo, adicione uma regra conforme mostrado na imagem a seguir. Essa regra instrui a reatribuir um bug à pessoa que o abriu quando um membro da equipe o resolve. Normalmente, essa pessoa verifica se o bug foi corrigido e o fecha. Para obter mais informações, consulte Aplicar regras a estados de fluxo de trabalho (processo de herança).

Captura de tela de regra definida para reatribuir bug com base no estado resolvido.

Definir o estado do item de trabalho na PR

Ao criar uma PR, 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 PR, o sistema lê a descrição e atualiza o estado do item de trabalho. O exemplo a seguir define os itens de trabalho nº 300 e nº 301 como Resolvido e nº 323 e nº 324 como Fechado.

Captura de tela da configuração do estado do item de trabalho em uma solicitação de pull.

Observação

Esse recurso requer a instalação do Azure DevOps Server atualização 2020.1. Para obter mais informações, consulte Notas de versão do Azure DevOps Server 2020 Atualização 1 RC1, Quadros.

Integração entre o 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. Vincule a objetos como builds, versões, branches, commits e PRs, conforme ilustrado na imagem a seguir.

O diagrama que mostra os tipos de link usados para vincular itens de trabalho a objetos de build e versão.

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

O controle Desenvolvimento oferece suporte à vinculação e à exibição de links a builds, commits do Git e solicitações de pull. Quando um repositório do TFVC é usado, ele oferece suporte a links para conjuntos de alterações e itens com controle de versão. Escolher o link abre o item correspondente em uma nova guia do navegador. Para obter mais informações, consulte Desenvolvimento do Git de unidade de um itemde trabalho.

A captura de tela mostra Controle de Desenvolvimento no formulário de item de trabalho com links de exemplo para builds, solicitações de pull e commits.

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

A captura de tela mostra Controle de Implantação no formulário de item de trabalho com versões de exemplo.

Muitas vezes, os pipelines são configurados para serem executados automaticamente quando ocorre um novo commit em um repositório Git. Os itens de trabalho associados aos pipelines de confirmação aparecerão como parte da execução do pipeline se você personalizar as configurações do pipeline. Para obter mais informações, consulte Personalizar seu pipeline.

Captura de tela das Configurações do Pipeline com Vincular itens de trabalho automaticamente nesta execução do branch destacado.

Criar ou editar um item de trabalho após uma falha de build

Se você usa pipelines clássicos (não YAML), pode criar itens de trabalho após uma falha de build. Para obter mais informações, consulte Criar um item de trabalho sobre falha.

Você pode rastrear o status, as atribuições e as tendências de bugs com consultas que podem ser mapeadas e adicionadas a um painel. Por exemplo, aqui temos dois exemplos mostrando tendências de bugs ativos por Estado e Bugs Ativos por Prioridade ao longo do tempo.

Captura de tela de dois gráficos de consulta de bug ativos, Tendências de Bug por Estado e por Prioridade.

Para mais informações sobre consultas, gráficos e painéis, confira consultas gerenciadas, gráficos e painéis.

Usar modos de exibição de Análise e o serviço de Análise para criar relatórios de bugs

O serviço analytics é a plataforma de relatórios do Azure DevOps. Ele substitui a plataforma anterior baseada no SQL Server Reporting Services.

Os modos de exibição de análise fornecem filtros pré-criados para exibir itens de trabalho. Há suporte para quatro modos de exibição de Análise para relatórios de bugs. Você pode usar esses modos de exibição conforme definidos 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 ver mais informações sobre o uso dos modos de exibição de Análise, consulte Sobre modos de exibição de Análise e Criar um relatório de bugs ativos no Power BI com base em um modo de exibição de Análise personalizado.

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

Relatórios de bugs predefinidos do SQL Server

Os relatórios a seguir têm suporte para processos Agile e CMMI.

Esses relatórios requerem o SQL Server Analysis Services e o SQL Server Reporting Services configurados para o projeto. Para saber como adicionar relatórios do SQL Server para um projeto, confira Adicionar relatórios a um projeto.

Extensões do Marketplace

Há várias extensões do Marketplace relacionadas a bugs. Confira Marketplace para o Azure DevOps.

Para saber mais sobre extensões, confira Extensões do Azure Boards desenvolvidas pela Microsoft.

Próximas etapas

Usar modelos para adicionar e atualizar itens de trabalho

Lista de pendências do produto e quadro

Quadro

Lista de pendências e Quadro de Tarefas do sprint

Integração no Azure DevOps

Recursos do setor