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? E 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. Além disso, você deseja gerenciar os defeitos de código de maneiras alinhadas às suas práticas Agile.

Para dar 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 ter uma visão geral dos recursos padrão, confira Recurso 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 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

  • Você precisa ser adicionado a um projeto.
  • Para exibir ou modificar itens de trabalho, você precisar ter as permissões de 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 definidas. Para obter mais informações, consulte Definir permissões e acesso para acompanhamento de trabalho.
  • Para adicionar novas marcas a serem adicionadas aos itens de trabalho, você deve ter acesso Básico ou superior e as permissões Criar definição de marca no nível do projeto devem estar definidas como Permitir. Por padrão, o grupo Colaboradores tem essas permissões definidas. Mesmo que a permissão seja definida explicitamente para um stakeholder, ele não tem permissão para adicionar novas marcas, pois isso é proibido pelo respectivo nível de acesso. Para mais informações, veja Referência rápida de acesso das partes interessadas.
  • Todos os membros do projeto, até os membros do grupo Leitores, podem enviar emails contendo itens de trabalho.
  • Você precisa ser adicionado a um projeto.
  • Para exibir ou modificar itens de trabalho, você precisar ter as permissões de 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 definidas. Para obter mais informações, consulte Definir permissões e acesso para acompanhamento de trabalho.
  • Para adicionar novas marcas a serem adicionadas aos itens de trabalho, você deve ter acesso Básico ou superior e as permissões Criar definição de marca no nível do projeto devem estar definidas como Permitir. Por padrão, o grupo Colaboradores tem essas permissões definidas. Mesmo que a permissão seja definida explicitamente para um stakeholder, ele não tem permissão para adicionar novas marcas, pois isso é proibido pelo respectivo nível de acesso. Para mais informações, veja Referência rápida de acesso das partes interessadas.
  • Todos os membros do projeto, até os membros do grupo Leitores, podem enviar emails contendo itens de trabalho.

Dica

Para relatar um bug, um usuário deve ter, no mínimo, acesso stakeholder e a permissão Editar itens de trabalho neste nó definida para Permitir para o caminho da área de em que adicionam o bug. Para obter mais informações, consulte Definir permissões e acesso para 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 rastreia informações semelhantes. Ele foi criado para aparecer 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 você vê 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.

Tipo de item de trabalho Bug, formulário para processo Scrum, Azure DevOps Server 2020 e serviço de nuvem.

Captura de tela do tipo de item de trabalho Bug, formulário para processo Scrum, Azure DevOps Server 2019 e TFS 2018.

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

Usage

Passos 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 sistema
Encontrado na Compilação

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 foi concluído satisfatoriamente.

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 que foram 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 saber como definir números de build, confira Opções de formato de número de build.

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 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. Além disso, 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. 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 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.
  • Como a equipe organiza o trabalho. 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
  • Pode arrastar e soltar bugs no painel Planejamento para 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 ficarã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 estão associados à Categoria de Bugs e não aparecem em listas de pendências nem quadros
  • Eles não ficam visíveis em Listas de Pendências, Quadros, Listas de Pendências de Sprint, Quadros de Tarefas nem Planos de Entrega
  • Não pode 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 rastrear problemas de software ou comentários do cliente. 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 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 o processo, recomendamos que você leia Configurar e personalizar o 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. Isso inclui listas de pendências, ferramentas de teste e quadros.

Dica

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

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

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

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

    Captura de tela para adicionar um bug da lista de pendências do produto, Adicionar bug.

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

    Captura de tela para adicionar um bug do quadro Kanban, Adicionar bug.

Dica

Quando você adiciona um bug da 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 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 optou por gerenciar bugs com tarefas, você pode definir bugs do quadro Kanban, 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
Captura de tela dos estados do fluxo de trabalho de bugs, modelo de processo Agile. Captura de tela dos estados do fluxo de trabalho de bugs, modelo de processo Scrum. Captura de tela dos estados do fluxo de trabalho de bugs, 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 mais trabalho for encontrado após um bug ter sido resolvido ou fechado, você poderá reativá-lo 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, confira Aplicar regras a estados de fluxo de trabalho, Automatizar 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 após ele ser verificado como corrigido. No entanto, você também pode fechar um bug por um dos motivos a seguir. Os motivos disponíveis para seleção 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

Após um bug ser 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. Em seguida, 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 – bugs abertos nas últimas três semanas (Created Date > @Today-21)

Quando tiver as consultas de interesse de sua equipe, você 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

Após começar a codificar e testar, é recomendável realizar reuniões periódicas de triagem para examinar e classificar os 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 rapidamente para cima e para baixo dentro da lista de itens de trabalho de bug usando 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 seguida, em cada sprint, você verá 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á-las 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 foi vinculado a um item de lista de pendências pai. Somente bugs e tarefas 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ê criou uma hierarquia de tarefas, bugs ou histórias de usuário, somente tarefas no nível filho ou histórias no nível filho no fim da hierarquia serão exibidas.
  • 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 a equipe rastreia bugs como requisitos, você pode usar o quadro Kanban para adicionar testes para verificar correções de bugs.

Captura de tela do quadro Kanban, 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 depois que ele for resolvido. 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. No exemplo a seguir, definimos 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 PR.

Observação

Esse recurso requer a instalação do Azure DevOps Server atualização 2020.1. Para saber mais, confira Notas sobre a 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.

Imagem conceitual 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 dá suporte à vinculação e à exibição de links a builds, commits do Git e PRs. Ou, quando um repositório do TFVC é usado, ele dá 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.

Controle de Desenvolvimento no formulário de item de trabalho com links de exemplo para builds, PRs 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.

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, Vincular itens de trabalho automaticamente nesta execução do branch selecionado.

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 Opções de build, Criar um item de trabalho sobre falha.

Você pode rastrear o status, as atribuições e as tendências de bugs usando 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 saber mais sobre consultas, gráficos e painéis, confira Sobre 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 de Análise é a plataforma de relatórios do Azure DevOps, substituindo a plataforma anterior baseada nos 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 saber mais sobre o uso dos modos de exibição de Análise, confira O que são os 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 poderia obter de uma consulta. Para obter mais informações, consulte Conectar-se ao Conector de Dados do Power BI.

Relatórios de bugs do SQL Server predefinidos

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

Esses relatórios exigem que você tenha 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 Kanban

Bloco Kanban

Lista de pendências e Quadro de Tarefas do sprint

Integração no Azure DevOps

Recursos do setor