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

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

Como você rastreia e gerencia defeitos em seu código? Como você garante que os problemas de software e os comentários dos clientes sejam resolvidos rapidamente para dar suporte a implantações de software de alta qualidade? 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

Pré-requisitos

• Acesso ao projeto: ser adicionado a um 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 acesso Básico ou superior 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 detentores de interesse 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.

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.

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.

---

Prioridade¹

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

---

Gravidade¹

Uma classificação subjetiva do impacto de um bug ou item de trabalho no projeto ou sistema de software. Por exemplo: Se um link remoto na interface do usuário (um evento raro) 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.

---

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

• Priorize, ou empilhar bugs, juntamente com os requisitos
• Estimar o esforço de bug para previsão
• Atualizar o status do bug a bordo
• Incluir bugs em gráficos de velocidade e diagramas de fluxo cumulativo
• Ser capaz de usar a ferramenta Previsão para apoiar o planejamento de sprint
• Arraste bugs para o painel Planejamento para atribuir bugs a um sprint
• Ver Bugs em Planos de Entrega

Nota

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

---

Rastreie bugs como tarefas

• Estimar o trabalho para bugs semelhantes a tarefas
• Atualizar o status do bug nos quadros de tarefas do sprint
• Vincular bugs a requisitos como itens filho
• 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.

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.

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

  

• Adicionar um bug da placa

  

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.

• Adicionar um bug filho vinculado a partir da lista de pendências da Sprint

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

  

• Adicionar um bug filho vinculado do quadro

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

  

Criar um bug a partir de uma ferramenta de teste

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

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

  

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

  

Ciclo de vida do bug e estados do fluxo de trabalho

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

Ágil	Scrum	CMMI

Para bugs do Scrum, você altera o Estado de Comprometido (semelhante ao Ativo) para Concluído. Para Agile e CMMI, você primeiro resolve o bug e seleciona um motivo que indica que o bug foi corrigido. Normalmente, a pessoa que criou o bug verifica a correção e atualiza o Estado de Resolvido para Fechado. Se você encontrar mais trabalho depois de 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 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.

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

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.

Organizar e atribuir bugs a um sprint

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

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

Se sua equipe rastrear bugs como tarefas, use consultas gerenciadas para listar e triar bugs. Em 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.

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.

  

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

  

Personalize sua placa para rastrear estados intermediários

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

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

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

Integração no Azure DevOps

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

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

Vincular itens de trabalho ao desenvolvimento

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

Vincular itens de trabalho a versões

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

Vincular itens de trabalho a execuções de pipeline

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

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

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

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

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

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

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

Artigos relacionados

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

Backlog de produtos e placa

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

Placa

• Sobre Boards e Kanban
• Use a sua prancha
• Reordenar cartões
• Adicionar tarefas ou itens filho como listas de verificação

Sprint backlog e Taskboard

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

Recursos da indústria

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