Glossário · Fundamentos de testes
Severidade de bug
Em inglês: Bug severity
Também chamado de: severidade do defeito, severidade de defeito, nível de severidade, gravidade do bug
Definição
O tamanho do impacto de um defeito no sistema ou nos usuários, de um crash completo ou perda de dados até um problema apenas cosmético; geralmente definida pelo QA.
A severidade de bug descreve o quanto um defeito afeta o produto: o que quebra, para quem, e se existe um workaround. É um julgamento técnico sobre impacto, e normalmente os testers a definem ao reportar o bug. A severidade não diz diretamente quando o bug será corrigido; isso é a prioridade.
Escala típica
Os nomes variam entre times e ferramentas, mas a maioria usa quatro ou cinco níveis:
| Severidade | Significado | Exemplo |
|---|---|---|
| Crítica / Bloqueante | Sistema fora do ar, perda ou corrupção de dados, falha de segurança, sem workaround | O checkout retorna 500 para todos os usuários |
| Maior / Alta | Uma funcionalidade principal está quebrada ou errada; o workaround é penoso ou não existe | Reembolsos calculados com a alíquota de imposto errada |
| Moderada / Média | Funcionalidade parcialmente quebrada, existe um workaround razoável | A exportação CSV ignora o filtro de data; dá para filtrar numa planilha |
| Menor / Baixa | Pequeno problema funcional com pouco impacto | A ordenação de uma lista pouco usada está invertida |
| Trivial / Cosmética | Problema visual ou de texto, sem efeito funcional | Ícone desalinhado, erro de digitação em um tooltip |
Severidade vs prioridade
Severidade = impacto do defeito (técnico, definido pelo QA). Prioridade = urgência da correção (negócio, definida pelo product owner ou na triagem).
Elas são independentes, e é por isso que entrevistadores pedem exemplos de cada combinação:
- Alta severidade, baixa prioridade: o app trava ao importar um formato de arquivo que um único cliente legado usa uma vez por ano.
- Baixa severidade, alta prioridade: o nome da empresa está escrito errado na página inicial na véspera de um lançamento.
- Alta severidade, alta prioridade: o pagamento falha para todos os usuários.
- Baixa severidade, baixa prioridade: um erro de digitação em uma página de configurações pouco acessada.
Erros comuns
- Inflar a severidade para o bug ser corrigido mais rápido. É para isso que existe a prioridade. Severidade inflada torna a métrica inútil.
- Classificar pelo trabalho que deu para encontrar. Classifique pelo impacto no usuário e no negócio, e diga quem é afetado e com que frequência.
- Ignorar o workaround. A mesma falha é mais severa quando não há como contorná-la.