Um nome de empresa escrito incorretamente na página inicial e uma falha em um recurso de exportação raramente usado: o que você corrige primeiro? Argumentos como esse explicam o motivo pelo qual as equipes de teste separam gravidade versus prioridade. Um descreve os danos técnicos e o outro descreve a urgência do negócio.

Sem essa distinção, todo bug é rotulado como “crítico”, os rótulos perdem o significado e os desenvolvedores deixam de confiar neles. Este guia fornece definições e exemplos claros, juntamente com um processo simples para tomar essas decisões. Os exemplos são ilustrativos e as escalas exatas diferem entre equipes e ferramentas.

A resposta curta

Gravidade responde: até que ponto esse bug afeta o produto? Uma falha ou perda de dados é grave, mas uma falha cosmética não.

Respostas prioritárias: quando devemos corrigir o problema? Isso depende dos clientes afetados, prazos, receitas, exposição legal e reputação da marca.

Pense em um hospital. Gravidade é a gravidade da condição do paciente. A prioridade é a ordem de atendimento dos pacientes, que depende também de outros fatores, como quem pode esperar com segurança e quais recursos são gratuitos.

Gravidade versus prioridade lado a lado

Níveis de gravidade

A maioria das equipes usa cerca de quatro ou cinco níveis. Aqui está uma escala comum:

Níveis de prioridade

Anote o que cada nível significa para sua equipe, de preferência com um tempo de resposta alvo para cada um. “P1 significa que alguém começa dentro de uma hora” é muito mais útil do que “P1 significa muito importante”.

As quatro combinações, com exemplos

A maneira mais clara de entender isso é observar cada combinação:

Alta gravidade, alta prioridade

O checkout falha para todos, a empresa perde dinheiro a cada minuto e não há solução alternativa. Este é o caso óbvio: largue tudo e conserte.

Alta gravidade, baixa prioridade

O aplicativo trava ao exportar para um formato legado. Tecnicamente, isso é uma falha grave. Mas se apenas uma pequena parcela de usuários usar esse recurso e um formato moderno funcionar bem, ele poderá esperar por um lançamento agendado.

Baixa gravidade, alta prioridade

O nome da empresa está escrito incorretamente na página inicial. Nada está quebrado e nenhum dado está em risco. No entanto, todo visitante vê isso, isso prejudica a confiança e, se um grande lançamento estiver previsto para amanhã, precisa ser consertado hoje.

Baixa gravidade, baixa prioridade

Um pequeno erro de digitação em um artigo de ajuda raramente visitado. Corrija-o quando for conveniente. Se o seu backlog estiver cheio disso, considere agrupá-los em uma tarefa de limpeza.

Um bug, duas prioridades diferentes

O mesmo defeito pode merecer prioridades diferentes dependendo do contexto. Suponha que um e-mail de confirmação de pedido seja enviado com o logotipo errado.

A gravidade não mudou porque o impacto no sistema é o mesmo. Mas a situação empresarial sim. O tempo também pode mudar as coisas. Um bug que é P3 hoje pode se tornar P1 uma semana antes do lançamento de um grande cliente.

Quem decide a gravidade e a prioridade?

• Os testadores geralmente propõem severidade, pois observaram o comportamento e compreenderam o impacto no sistema.
• Proprietários ou gerentes de produtos geralmente decidem a prioridade, pois avaliam os clientes, a receita e o roteiro.
• Desenvolvedores adicionam informações sobre a causa, o risco de uma correção e quanto tempo levará.
• As equipes de suporte trazem evidências de quantos clientes foram afetados e até que ponto.

As fontes e as equipes variam quanto a essas responsabilidades e, em uma pequena startup, uma pessoa pode fazer tudo isso. O que importa é que todos saibam quem toma a decisão final, para que as divergências terminem com uma decisão.

Como avaliar um bug

Quando não tiver certeza, resolva essas questões.

Para gravidade:

1. Ele perde ou corrompe dados ou expõe informações privadas?
2. Isso impede o funcionamento de uma função principal?
3. Existe uma solução alternativa e um usuário normal poderia encontrá-la?
4. Quanto do recurso é afetado?

Para prioridade:

1. Quantos usuários são afetados e quais?
2. Custa dinheiro ou cria riscos legais ou de conformidade?
3. Um lançamento, demonstração ou venda está chegando?
4. Quão visível é isso e pode prejudicar sua reputação?
5. Bloqueia outros trabalhos, como testes?

Executando triagem de bugs

A triagem é a reunião regular onde uma equipe analisa novos bugs e decide o que acontece a seguir. Um formato simples funciona bem:

1. Preparar. O testador garante que cada novo bug tenha etapas claras, evidências e gravidade proposta.
2. Confirme. Verifique se pode ser reproduzido e não é duplicado.
3. Decida. Combine a gravidade, defina uma prioridade e atribua um proprietário.
4. Feche o ciclo. Rejeite, adie ou agende cada bug e registre o motivo.

Seja curto e frequente. Durante os últimos dias antes da liberação, é comum uma triagem diária de 15 minutos. A gravidade e a prioridade também influenciam sua decisão de lançamento, portanto, defina regras antecipadamente, como “nenhum bug S1 ou S2 aberto no lançamento”, como parte de seus critérios de saída.

Gravidade e prioridade em um relatório de bug

Uma entrada curta e clara ajuda todos a tomar uma boa decisão:

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Esses números são exemplos. Em um relatório real, use números medidos em seus registros e explique seu raciocínio. Saiba mais em nosso guia sobre como escrever um relatório de bug. Também ajuda saber o que significam os códigos de erro, portanto, mantenha nossa folha de dicas sobre códigos de status HTTP à mão.

Erros comuns

• Tratá-los como o mesmo campo. Se os dois sempre corresponderem, você estará perdendo informações úteis.
• Inflar a severidade para chamar a atenção. Uma vez que tudo é crítico, nada o é.
• Deixar os testadores definirem a prioridade sozinhos. Eles raramente têm uma visão completa do negócio.
• Nunca revise o backlog. As prioridades ficam obsoletas, então verifique novamente os bugs antigos regularmente.
• Não há definições escritas. Sem elas, as pessoas aplicam rótulos de maneira diferente e você acaba debatendo palavras.
• Ignorar acúmulos de baixa gravidade. Cinquenta problemas menores podem fazer um produto parecer quebrado, mesmo que nenhum deles seja sério por si só.

Considerações finais

Mantenha as duas questões separadas: quão ruim é e quando deve ser corrigido? Combine as definições escritas para cada nível e deixe claro quem decide. Na próxima etapa, pegue os dez bugs mais antigos do seu rastreador e reavalie-os usando as perguntas acima. Você provavelmente encontrará alguns que deveriam ser movidos e outros que deveriam ser fechados.

Perguntas frequentes

Continue aprendendo