Classificando e priorizando bugs

Erros são inevitáveis. Mesmo os melhores especialistas em garantia de qualidade (QA) não podem garantir sua ausência nos produtos que lançam no mercado, embora possam fazer uma revisão completa dos sistemas, desempenho, funcionalidade e outros aspectos de um software que estão testando. .

Claro, é fundamental detectar o maior número possível de bugs antes de lançar um produto. E uma etapa importante e contínua nesse processo é classificar e priorizar esses defeitos.

Por que você precisa classificar e priorizar bugs?

Há uma série de razões pelas quais esta etapa é crítica no SDLC. Talvez o mais importante seja garantir que a equipe se concentre e resolva primeiro os bugs mais importantes – aqueles que têm maior probabilidade de afetar negativamente a experiência do usuário com o produto. Se você não der esse passo importante – ou melhor, uma série de passos – poderá perder tempo dedicando muita atenção a questões menores.

Construir um sistema para essa finalidade também permite melhorar a organização e tornar os processos de desenvolvimento e controle de qualidade mais tranquilos. A organização é fundamental na criação de software robusto porque há muitas partes móveis.

Além disso, tal sistema orientará os esforços de sua equipe. Eles compreenderão melhor para onde direcionar seus esforços, permitindo-lhes resolver melhor defeitos importantes antes que causem estragos no produto e implementem novos recursos.

Como classificar e priorizar por prioridade e gravidade do bug

Existem 2 formas estabelecidas de classificar e priorizar bugs: classificação por prioridade e classificação por gravidade.

1. Classificação por prioridade

A maioria das empresas de desenvolvimento usa um sistema de classificação para classificar bugs nessas categorias, usando uma escala numérica de 1 a 5 ou identificando o problema como prioridade muito alta, prioridade alta, prioridade média, prioridade baixa ou prioridade muito baixa. Prioridade faz referência à ordem em que um bug deve ser resolvido. Em outras palavras, quantos bugs – se houver algum – devem ser corrigidos antes deste? De modo geral, as classificações se correlacionam da seguinte forma:

• Plataformas de CRM: O bug requer atenção urgente ou ninguém conseguirá usar o produto ou recurso específico com sucesso.
• Alta prioridade: o bug está interferindo no produto para a maioria da sua base de consumidores. O bug requer atenção assim que você resolver bugs de alta prioridade.
• Prioridade média: o bug pode interferir na experiência de alguns usuários com seu produto. Isso pode esperar, embora você deva resolver o problema mais cedo ou mais tarde.
• Baixa prioridade: embora o bug seja aparente, é improvável que afete a grande maioria dos usuários e a forma como eles interagem com seu produto. Você provavelmente pode deixar isso por enquanto e se concentrar em bugs de maior prioridade.
• Prioridade muito baixa: O bug é quase imperceptível e terá pouco impacto na experiência da maioria dos usuários com o produto. Você provavelmente terá problemas para reproduzir esse bug e poderá deixá-lo para ser resolvido posteriormente.

A maioria das empresas de desenvolvimento usa um sistema de classificação para classificar bugs nessas categorias, usando uma escala numérica de 1 a 5 ou identificando o problema como prioridade muito alta, prioridade alta, prioridade média, prioridade baixa ou prioridade muito baixa. Prioridade faz referência à ordem em que um bug deve ser resolvido. Em outras palavras, quantos bugs – se houver algum – devem ser corrigidos antes deste? De modo geral, as classificações se correlacionam da seguinte forma:

2. Classificação por gravidade

A gravidade de um bug refere-se ao escopo do problema e à extensão em que o defeito afetará o sistema como um todo. Assim como a prioridade, os problemas são classificados da seguinte forma:

• Gravidade muito alta: O produto torna-se inútil sem a intervenção dos desenvolvedores de software.
• Alta gravidade: o produto frequentemente encontra problemas que afetam aspectos como funcionalidade, desempenho ou usabilidade.
• Gravidade média: embora o bug não afete gravemente o programa como um todo, ele tem algum impacto no produto.
• Baixa gravidade: o bug quase não afeta negativamente os principais recursos do produto.
• Gravidade muito baixa: o produto ou qualquer um de seus principais recursos não são afetados pelo bug.

Como criar uma matriz de prioridade e gravidade de bugs

Para determinar quais bugs serão resolvidos primeiro, você precisa realizar uma análise completa do que encontrou e categorizar cada um dos eventos em uma matriz útil e prática. A Matriz de Prioridade e Gravidade de Bugs leva em consideração a prioridade e a gravidade dos bugs registrados e ajuda a visualizar todos os eventos em quadrantes, classificados pela intensidade do impacto deles em seu projeto.

Dessa forma, ao analisar os bugs e imputá-los na matriz você terá quatro seções principais, mostrando esses eventos como Alta Prioridade e Alta Gravidade, Alta Prioridade e Baixa Gravidade, Baixa Prioridade e Alta Gravidade, e Baixa Prioridade e Baixa Gravidade. .

Quem determina a prioridade do bug?

A análise de bugs é um processo complexo e detalhado que deve ser conduzido por especialistas experientes que possam determinar quais problemas terão o impacto mais sério na capacidade do projeto ser concluído dentro do prazo e do orçamento. A determinação real da prioridade dos bugs deve ser feita pelo especialista sênior que supervisiona o projeto, como um gerente de projeto ou proprietário do produto. Isso, porém, deve ser feito com a participação do cliente, para que tudo fique alinhado e todos os detalhes fiquem claros para todos os envolvidos.

Como o Agile e o SCRUM lidam com bugs de produção?

Ágil e SCRUM são algumas das metodologias mais populares e eficazes para gerenciamento de projetos. Cada um deles tem seus próprios métodos para lidar com bugs, com etapas e resultados claramente definidos.

Ágil

O Agile começa classificando os bugs em baixa, média ou alta prioridade, para determinar quando o problema será resolvido. Se houver uma solução alternativa disponível e corrigi-la imediatamente tiver um impacto maior, será determinado que o bug será resolvido posteriormente. No entanto, se houver um bug na funcionalidade principal do produto, a correção deverá ser implementada imediatamente. Para isso, a equipe Agile determina um número fixo de horas que serão dedicadas à solução do problema e trabalharão para resolvê-lo.

SCRUM

No caso do scrum, a prioridade do bug é definida pelo product owner, que também determina se este é um problema que precisa ser resolvido agora ou que pode esperar até o final do sprint. Caso decidam esperar, o bug vai para o backlog, para ser resolvido posteriormente. Quando chegar a hora de lidar com o problema, o proprietário do produto pede à equipe um voluntário para resolvê-lo, que então procede à correção enquanto o restante da equipe continua trabalhando para avançar o projeto.

Coisas a ter em mente

Determine como cada defeito se relaciona com a experiência do cliente

Freqüentemente, a severidade e a prioridade andam de mãos dadas – ambas afetam a qualidade geral do produto. Mas às vezes você pode ter problemas conflitantes em jogo. Por exemplo, um bug pode ser de alta gravidade e baixa prioridade, o que significa que resultaria em um sistema inútil apenas para um pequeno subconjunto de usuários. Por outro lado, um defeito pode ser de baixa gravidade e alta prioridade, o que significa que o problema em si não está interferindo na funcionalidade geral ou na usabilidade do sistema, embora esteja impactando a grande maioria da sua base de consumidores. Então, como você decide entre essas 2 métricas? Em última análise, geralmente tudo se resume à experiência do usuário. Em outras palavras, pense em como o bug está afetando seu público-alvo. Isso o ajudará a avaliar a quantidade de atenção que você precisa dedicar a ele e a precedência que deve ter.

Faça suposições

Integração de software

Simplifique seu fluxo de trabalho com nossos serviços de integração de software. Nossos engenheiros de alto desempenho analisarão a maneira como você usa atualmente tecnologias de software (sejam elas de terceiros ou personalizadas) e ajudarão você a estabelecer uma infraestrutura de TI robusta e bem coordenada em todos os departamentos da sua organização. Também construímos microsserviços, APIs e protocolos de dados personalizados.