Neste guia
Duas palavras vivem sendo confundidas. Severidade é o quão grave o bug é para o usuário: o que quebra. Prioridade é a rapidez com que você o corrige: uma decisão que também depende de quantas pessoas são afetadas, de quão fácil é um contorno e da data do seu release. Um desenvolvedor solo precisa definir as duas uma vez, para que o mesmo bug receba a mesma classificação na segunda-feira e na sexta-feira.
Definições de severidade (copie e adapte)
S1 Crítica O app trava, dados são perdidos ou corrompidos, uma cobrança é feita
incorretamente, ou um fluxo principal não pode ser concluído. Sem contorno.
S2 Grave Uma funcionalidade principal está quebrada ou muito difícil de usar, mas
existe um contorno.
S3 Menor Uma funcionalidade não principal se comporta mal, ou uma principal em um
caso extremo.
S4 Trivial Cosmético: erro de digitação, desalinhamento, pequeno defeito visual.
Alcance (quantas são afetadas)
Muitas A maioria dos usuários ou todos, em um dispositivo / SO / fluxo comum
Algumas Um grupo claramente definido (uma família de dispositivos, um idioma, um tipo de conta)
Poucas Condições raras ou um único caso relatado
A matriz
Prioridade a partir da severidade (linhas) e do alcance (colunas):
| Muitas | Algumas | Poucas | |
|---|---|---|---|
| S1 Crítica | P0: corrigir agora, parar o release | P0: corrigir agora | P1: corrigir antes do release |
| S2 Grave | P1: corrigir antes do release | P1: corrigir antes do release | P2: próximo release |
| S3 Menor | P2: próximo release | P2 ou P3 | P3: backlog |
| S4 Trivial | P3: backlog | P3: backlog | P3: backlog, ou fechar |
Significados das prioridades: P0 deixe tudo de lado. P1 precisa ser corrigido antes de este release sair. P2 planeje para o próximo release. P3 backlog, corrija quando estiver por perto.
Template para classificar um bug (copie e cole)
BUG: <título>
Severidade: S<1-4> Alcance: <muitas / algumas / poucas> Prioridade: P<0-3>
Contorno: <sim: descreva / não>
Por que esta classificação: <uma frase>
Decisão: <corrigir agora / antes do release / próximo release / backlog> Data: <data>
Exemplo (ilustrativo)
BUG: App trava ao salvar com título vazio
Severidade: S1 Alcance: Algumas (só usuários que pulam o campo de título) Prioridade: P0
Contorno: Digitar um título
Por que esta classificação: Crash com perda de dados na ação principal de salvar; um contorno não elimina o crash.
Decisão: corrigir agora Data: 2026-11-05
Como adaptar
- Desvie com um motivo. As regras servem para os 90 por cento; anote por que quebrou uma delas.
- Eleve a prioridade de riscos que estão além da matriz: problemas de segurança ou privacidade, erros de pagamento e qualquer coisa que possa violar as regras da loja não devem esperar. Confira as políticas atuais para o último caso.
- Use dados reais quando tiver. Relatórios de crash mostram o alcance; veja [como priorizar relatórios de crash e [como priorizar feedback de apps.
- No máximo quatro níveis. Mais níveis significam mais discussão e nenhuma decisão melhor.
- Diga aos testadores o que você quer dizer, para que os palpites de severidade deles batam com os seus; a decisão final continua com você.
Relacionados
- Hub: Hub de checklists de teste de apps mobile
- [Lista de problemas conhecidos para testadores
- [Checklist de go / no-go para release
Comece grátis para reunir relatórios de bugs de forma estruturada e depois classifique-os com esta matriz.