Partilhar via

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

  • Artigo

Azure DevOps Services | 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? Como você faz um bom progresso em novos recursos e lida 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. 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 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 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

  • Acesso ao projeto: Seja um membro do projeto.

  • Permissões:

    • Tenha as 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 essas permissões. Para obter mais informações, consulte Definir permissões de controle de trabalho.

    • Para adicionar novas tags a itens de trabalho, tenha pelo menos acesso Básico e a permissão Criar nova definição de tag no nível do projeto definida como Permitir. Por padrão, o grupo de Colaboradores tem essa permissão.

      Nota

      Os participantes não podem adicionar novas tags, mesmo que a permissão esteja explicitamente definida, devido ao seu nível de acesso. Para obter mais informações, veja Referência rápida sobre o acesso de Interveniente.

  • Itens de trabalho por e-mail: Todos os membros do projeto, incluindo aqueles no 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 . Um usuário deve ter a permissão Editar itens de trabalho neste nó definida como Permitir o Caminho da Área onde ele adiciona o bug. Para obter mais informações, consulte Definir permissões de 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 and Capability Maturity Model Integration (CMMI) 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.

Nota

As imagens que você vê do seu portal da Web podem ser diferentes 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.

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

A captura de tela mostra um formulário de tipo de item de trabalho de 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 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

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. Inclua ações tomadas para localizar ou reproduzir o bug e o comportamento esperado.

Informações do sistema encontradas 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 Configuração clássica de pipelines.

Prioridade1

  • 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.

Gravidade1

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) fizer com que um aplicativo ou página da Web falhe (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. 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. 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.
  • Organização do trabalho da sua equipa. 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

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
  • Arraste bugs para o 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 sã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 aparecem em listas de pendências ou placas
  • Os bugs não são visíveis em Listas de Pendências, Quadros, Listas de Pendências da Sprint, Quadros de Tarefas ou Planos de Entrega
  • Não é possível 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 acompanhar problemas de software ou comentários de clientes. 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 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 Sobre como configurar e personalizar os Painéis do Azure.

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

Para personalizar seu processo específico, consulte 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 e quadros e ferramentas de teste.

Gorjeta

Por padrão, o campo Título é o único campo obrigatório quando você cria um bug. Você pode adicionar bugs 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. Você pode tornar alguns campos obrigató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.

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 ou placa de produtos. Para obter mais informações, consulte Criar sua lista de pendências de produtos ou Usar sua placa.

  • 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 da placa

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

Gorjeta

Quando você adiciona um bug da sua lista de pendências ou placa do produto, o bug é automaticamente atribuído ao Caminho de Área e 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 do seu quadro, 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.

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.

    A captura de tela mostra o Test Runner, onde você pode adicionar um bug.

  • 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.

    A captura de tela mostra a extensão Test & Feedback, onde você pode adicionar um bug ou recurso de tarefa.

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
O diagrama mostra os estados do fluxo de trabalho de bugs no modelo de processo Agile. O diagrama mostra os estados do fluxo de trabalho de bug no modelo de processo do Scrum. O diagrama mostra os estados do fluxo de trabalho de bug no modelo de processo 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 você encontrar mais trabalho depois de resolver ou fechar um bug, reative-o 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 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 quando um membro da equipe o verifica como corrigido. No entanto, você também pode fechar um bug por um dos seguintes motivos. Os motivos disponíveis 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

Depois que um bug é fechado e a correção é 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. 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, como bugs abertos nas últimas três semanas (Created Date > @Today-21)

Quando você tem 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, realize 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 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.

Captura de ecrã do painel Direito dos Resultados da Consulta, Bugs Ativos e Modo de Triagem.

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:

Se sua equipe rastrear bugs como tarefas, use consultas gerenciadas para listar e triar bugs. Em cada sprint, você vê 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 está vinculado a um item de lista de pendências pai. Somente bugs e tarefas são vinculados 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 que o sprint apareça 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ê criar 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 aparecerão. Para obter mais informações, consulte Solucionar problemas de reordenação e aninhamento.
  • 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 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 status do bug

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

  • Se sua equipe rastrear bugs como requisitos, você usará o quadro como mostrado na imagem a seguir. Para obter mais informações, consulte Atualizar status do item de trabalho.

    Captura de tela de um quadro, onde você pode arrastar um bug para atualizar o status.

  • 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.

    Captura de ecrã do Quadro de Tarefas, onde pode arrastar um bug para atualizar o estado.

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:

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 quando um membro da equipe o resolve. 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).

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

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. O exemplo a seguir define os itens de trabalho #300 e #301 como Resolvido e #323 e #324 como Fechado.

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

Nota

Esse recurso requer a instalação da atualização do Azure DevOps Server 2020.1. Para obter mais informações, consulte Azure DevOps Server 2020 Update 1 RC1 Release Notes, Boards.

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.

Diagrama que mostra os tipos de link usados para vincular itens de trabalho para criar e liberar objetos.

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

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. 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.

A captura de tela mostra o controle de desenvolvimento no formulário de item de trabalho com links de exemplo para compilar, receber solicitações e confirmaçõ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.

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

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.

Captura de tela de Configurações de pipeline com Vincular automaticamente itens de trabalho nesta execução a partir da ramificação selecionada realçada.

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 Criar um item de trabalho em caso de falha.

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.

Captura de tela de dois gráficos de consulta de bugs ativos, Tendências de bugs por estado e por prioridade.

Para obter mais informações sobre consultas, gráficos e painéis, consulte consultas gerenciadas, 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. Ele substitui 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 obter mais informações sobre como usar modos de exibição analíticos, consulte Sobre 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 uma consulta. Para obter mais informações, consulte Conectar-se com o Power BI Data Connector.

Relatórios de bugs predefinidos do SQL Server

Os relatórios a seguir são suportados 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 seu projeto. Para saber como adicionar relatórios do SQL Server para um projeto, consulte Adicionar relatórios a um projeto.

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

Backlog de produtos e placa

Placa

Sprint backlog e Taskboard

Integração no Azure DevOps

Recursos da indústria