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

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

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.

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.

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.

---

Prioridade¹

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

---

Gravidade¹

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.

---

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

¹ 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

• Priorizar ou classificar os bugs com os requisitos
• Estimar o esforço do Bug para previsão
• Atualizar o status do bug no quadro
• Incluir Bugs em Gráficos de velocidade e Diagramas de fluxo cumulativo
• Ser capaz de usar a ferramenta Forecast para oferecer suporte ao planejamento de sprints
• Arrastar bugs para o painel Planejamento e atribuir bugs a um sprint
• Exibir Bugs em Planos de entrega

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.

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.

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

  

• Adicionar um bug do quadro

  

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.

• Adicionar bug filho vinculado da lista de pendências do sprint

  Você adiciona um bug da mesma maneira como adiciona uma tarefa a uma lista de pendências do sprint. Para obter mais informações, consulte Adicionar tarefas a itens de lista de pendências.

  

• Adicionar um bug filho vinculado a partir do quadro

  Você adiciona um bug da mesma maneira 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.

  

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.

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

  

• Extensão de Teste e Comentários: 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 Teste e Comentários.

  

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

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.

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.

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.

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.

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:

• Organize bugs em sua lista de pendências. Classifique em ordem de prioridade em relação a outros itens. A classificação é desabilitada quando a filtragem está habilitada.
• Atribuir bugs a um sprint da lista de pendências usando o painel Planejamento.
• Mapeie bugs como pai para recursos ou outros itens de lista de pendências de portfólio com o painel Mapeamento.
• Exibir o acúmulo de trabalho para itens da lista de pendências do portfólio.

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.

Atualizar o status dos bugs

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

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

  

• Se a equipe rastrear bugs como tarefas, você usará o Quadro de Tarefas. Para obter mais informações, consulte Atualizar e monitorar seu Quadro de Tarefas.

  

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

Definir o estado do item de trabalho na PR

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.

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

Vincular itens de trabalho ao desenvolvimento

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.

Vincular itens de trabalho a versões

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.

Vincular itens de trabalho a execuções de pipeline

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.

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.

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

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.

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

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

Artigos relacionados

• Remover, excluir ou restaurar itens de trabalho
• Copiar ou clonar um item de trabalho

Lista de pendências do produto e quadro

• Usar listas de pendências para gerenciar projetos
• Criar sua lista de pendências
• Definir recursos e épicos
• Organizar sua lista de pendências e mapear itens de trabalho filho para os pais
• Filtrar interativamente listas de pendências, quadros, consultas e planos
• Prever a lista de pendências do produto

Quadro

• Sobre quadros e Kanban
• Usar seu quadro
• Reordenar cartões
• Adicionar tarefas ou itens filho como listas de verificação

Lista de pendências e Quadro de Tarefas do sprint

• Saiba mais sobre as práticas recomendadas do Scrum
• Atribuir itens da lista de pendências a um sprint
• Adicionar tarefas
• Atualize seu 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 uma PR
• Configurar números de execução ou de build

Recursos do setor

• Dívida técnica boa e ruim (e como o TDD ajuda) por Henrik Kniberg
• Gerenciando a dívida técnica, postado por Sven Johann e Eberhard Wolff