Glossário · Fundamentos de testes
Prioridade de bug
Em inglês: Bug priority
Também chamado de: prioridade do defeito, prioridade de defeito, nível de prioridade
Definição
O quão urgente é corrigir um defeito em relação ao restante do trabalho, decidido pela necessidade do negócio; geralmente definida pelo product owner ou na triagem de bugs.
A prioridade de bug descreve a ordem em que os defeitos são corrigidos. É uma decisão de negócio que pondera impacto no usuário, prazos, compromissos com clientes, reputação e o custo da correção. Os testers podem sugerir uma prioridade, mas a palavra final normalmente é do product owner, muitas vezes em uma reunião de triagem com desenvolvimento e QA.
Escala típica
| Prioridade | Significado |
|---|---|
| P1 / Urgente | Corrigir imediatamente; pode exigir um hotfix fora do release normal |
| P2 / Alta | Corrigir na sprint atual ou antes do próximo release |
| P3 / Média | Planejar para uma sprint futura |
| P4 / Baixa | Corrigir quando for conveniente, ou aceitar e fechar |
Prioridade vs severidade
A severidade mede o impacto: o quanto o produto está quebrado. A prioridade mede a urgência: quão cedo precisa ser corrigido. Elas são avaliadas separadamente porque muitas vezes não batem.
- Baixa severidade, alta prioridade: um preço errado exibido em um banner de uma campanha que entra no ar amanhã. Nada trava, mas tem que estar certo antes do lançamento.
- Alta severidade, baixa prioridade: um crash em um relatório administrativo que só roda no fechamento do ano, daqui a onze meses.
A prioridade também muda com o tempo, enquanto a severidade normalmente não. Esse mesmo crash de fechamento de ano vira P1 em dezembro.
Como a prioridade é decidida
Perguntas úteis durante a triagem:
- Quantos usuários são afetados, e quais (clientes pagantes, equipe interna, um único tenant)?
- Existe um workaround, e o suporte consegue explicá-lo?
- Existe algum prazo de release, demo, legal ou contratual?
- Qual é o custo e o risco da própria correção? Uma correção arriscada no fim de um release pode ser adiada de propósito.
Erros comuns
- Usar um único campo para as duas coisas. Times que registram só a “prioridade” perdem a informação sobre impacto, que importa para o risco do release e para as métricas.
- Tudo é P1. Quando a maioria dos bugs é urgente, nenhum é. Mantenha o nível mais alto raro e bem definido.
- Nunca rever a prioridade. Reavalie os bugs abertos quando o plano de release ou a situação do cliente mudar.