A atual classificação de bugs (usando labels do GitHub) é muito simplista, não dando nenhuma informação sobre o quão grave é o bug ou sua prioridade de resolução.
Abaixo está uma classificação comumente usada na indústria [1]:
- Severidade
- S1 - Crítica / Show Stopper
- Bloqueia o teste de uma função ou feature causa crash na aplicação nos principais casos de uso
- Botão não funciona, impedindo o uso da feature
- Segurança
- Feature esperada não aparece na build
- Perda grave de dados
- Bloqueia release
- Bloqueia o teste de uma função ou feature causa crash na aplicação nos principais casos de uso
- S2 - Grave
- Feature funciona pobremente
- Input esperados causam crash ou efeitos indesejados
- Input incomum causa efeitos irreversíveis
- Feature funciona pobremente
- S3 - Moderada
- Feature não atinge certos critérios de aceitação, mas sua funcionalidade em geral não é afetada
- Mensagem de erro ou sucesso não é exibida
- Input incomum causa efeitos indesejados, mas contornáveis
- Feature não atinge certos critérios de aceitação, mas sua funcionalidade em geral não é afetada
- S4 - Pequena
- Quase nenhum impacto na funcionalidade, mas ainda é um erro válido
- Erro ortográfico
- Pequenos erros de UI
- Quase nenhum impacto na funcionalidade, mas ainda é um erro válido
- S1 - Crítica / Show Stopper
- Prioridade
- P1 - Crítico
- Tem que ser solucionado imediatamente
- Erros de severidade S1 encontrados produção
- Erros de UI que afetam feeling/UX
- Tem que ser solucionado imediatamente
- P2 - Alta
- Feature não é usável como deveria ser, por problema no código
- Configuração de dependências
- Detalhes da feature não levantados durante seu desenvolvimento
- Deadlines do projeto
- Feature não é usável como deveria ser, por problema no código
- P3 - Média
- Problemas que podem ser avaliados para entrar no ciclo de desenvolvimento no futuro; dependendo dos recursos disponíveis
- Efeitos indesejados quando o sistema é submetido a inputs incomuns ou não-existentes no ambiente do usuário
- Problemas que podem ser avaliados para entrar no ciclo de desenvolvimento no futuro; dependendo dos recursos disponíveis
- P4 - Baixa
- Erros que não afetam funcionalidade
- Pequenas melhorias de UI e UX
- Erros de digitação
- Erros que não afetam funcionalidade
- P1 - Crítico
Vejo essa classificação como uma informação interessante para tomarmos decisão de release de versões e indicar interesse da comunidade (e dos usuários) na resolução de um bug em particular.
Essa classificação pode ser facilmente implementada usando as labels do GitHub.
O que acham?