Padrões para definição de criticidade de bugs

Versão 1.1 de 26/12/2016

Bugs funcionais

Crítico

Definição

Geralmente reservado para erros fatais, indicam que o teste não pode continuar sem correção, e/ou o negócio não consegue utilizar a aplicação ou a TI não consegue operar o serviço. Deve ser corrigido obrigatoriamente antes de ir para produção.

Características

1. Falha geral da aplicação
2. Perda de dados
3. Instabilidade da aplicação ou de seus serviços (impede o uso)
4. Impede uso da aplicação ou continuidade dos testes
5. Build da aplicação corrompido
6. Funcionalidades principais severamente comprometidas ou impossível de ser utilizada
7. Bugs que ocorrem sempre e que o usuário não consegue contornar.

Exemplos de erros desse grau de severidade

• O erro não permite a continuidade dos testes ou compromete severamente o resultado dos mesmos;
• Erros de Java, PHP, SQL, etc., sendo exibido ao usuário final;
• “Fatal error”;
• Funcionalidade desenvolvida em desacordo com os requisitos especificados (desvio significativo) e/ou das regras de negócio do cliente;
• Problemas graves de desempenho;
• Incompatibilidade com os browsers definidos como suportados no projeto, ou outros itens de ambiente;
• Links quebrados;
• Loops infinitos;
• Produtos cartesianos em consultas/relatórios;
• Problemas de acesso e segurança de perfis de usuários. Por exemplo: usuário de um perfil possui acesso a informações que não deveria visualizar;
• Principal ação de um botão não funciona. Por exemplo: o botão "Limpar" de uma tela não limpa os campos preenchidos;
• Restrição de integridade. Por exemplo: o registro pode ser excluído do sistema, sendo que possui dependência com outros registros.

Grave

Definição

Usado quando existe um problema que permite que o teste continue, porém utilizando condições de contorno (workarounds) complexas. Também quando há impactos significativos na possibilidade do uso da apliçação pela área de negócios ou na capacidade da TI de operar o serviço. Deve ser corrigido obrigatoriamente antes de ir para produção.

Características

1. Sério comprometimento de funcionalidades, mas consegue usar o sistema
2. Funcionalidade periférica impossível de ser utilizada
3. Sistema travando (dificulta o uso mas funciona)
4. Bug em funcionalidade essencial do produto
5. Condições de contorno (workarounds) complexos
6. Comprometimento moderado da continuidade dos testes
7. Bugs que ocorrem sempre, mas o usuário possui ao menos uma alternativa para contornar.
8. Bugs que ocorrem às vezes ou raramente, porém o usuário não consegue contorná-los.

Exemplos de erros desse grau de severidade

• Funcionalidade desenvolvida em desacordo com os requisitos especificados (desvio moderado);
• Problemas perceptíveis de desempenho com razoável impacto no uso normal da aplicação;
• Regras de validação de campos não aplicadas corretamente (data inválida, valor fora da faixa, etc.);
• Obrigatoriedade dos campos;
• Ação secundária do botão. Por exemplo: o botão Limpar, limpa os campos preenchidos e realiza a pesquisa dos registros cadastrados.

Moderado

Definição

Usado quando há um problema que significa que o teste pode continuar com condições de contorno (workarounds) relativamente simples.Também quando há um impacto reduzido na capacidade de utilização da aplicação pelas equipes de negócios ou na capacidade de TI para operar o serviço. Negócios e TI devem, juntos, definir se o bug deve ser corrigido antes de ir para Produção.

Características

1. Problemas moderados em funcionalidades do produto
2. Gambiarra simples
3. Baixo impacto dos testes
4. Ergonomia (usabilidade) razoavelmente comprometida
5. Erros de ortografia/gramática
6. Bugs que ocorrem sempre, mas o usuário consegue realizar a tarefa sem impacto.
7. Bugs que ocorrem às vezes, mas existem alternativas para contorná-los.

Exemplos de erros desse grau de severidade

• Layout de tela/relatório fora dos padrões.
• Layout de tela/relatório ergonomicamente inadequado (usabilidade).
• Falta de valores padrões para campos quando aplicável.
• Navegação fora de ordem entre os componentes da tela.
• Teclas de atalho padrão não desenvolvidas corretamente.
• Foco setado incorretamente.
• Imagens não carregadas.
• Erros de ordenação/quebra em consultas e relatórios.
• Termos inadequados/fora do contexto.
• Erros de ortografia/digitação.
• Mensagens de erro não são claras e devem ser reescritas;
• Ocorre quando o produto ou aplicação não atender a certos critérios, ou ainda exibe um comportamento não natural, no entanto, a funcionalidade como um todo não é afetado.

Baixo

Definição

Usado para destacar problemas menores que não impactam o uso do sistema pela equipe de negócios ou pela TI de operar o sistema. O sistema pode ir para produção com este bug, porém esse erro deve ficar registrado no backlog.

Características

1. Não chega a comprometer o objetivo da funcionalidade
2. Afeta a aparência da funcionalidade
3. Bugs que ocorrem raramente e o usuário consegue realizar a tarefa normalmente e/ou existem alternativas.
4. Bugs que ocorrem às vezes e o usuário consegue realizar a tarefa normalmente.

Exemplos de erros desse grau de severidade

• Layout de tela/relatório esteticamente inadequado.
• Problemas com layout e aparência.
• Erros de documentação.
• Alinhamento de campos inadequado.
• Falta de clareza em mensagens para o usuário.
• Problemas na usabilidade/navegação das telas.

Melhoria

Definição

Não são erros, mas oportunidades de melhorias identificadas. Trata-se de um registro pró-ativo da equipe de teste pois entende-se que existe uma grande probabilidade do cliente sugerir isso no futuro. Anteriormente, na MSTECH, essa criticidade era tratada como QoS (Quality of Service). Pode ir para produção, porém o PO deve analisar se é pertinente a sugestão. Caso não seja deve justificar e fechar este bug.

Exemplos de erros desse grau de severidade

• Telas/relatórios com layout adequado, mas com oportunidade de melhoria.
• Sugestão de termos.
• Cores

Bugs de usabilidade e layout

Conformidade

Os bugs da subcategoria Conformidade, quando uma parte do sistema está fora dos padrões do próprio sistema ou da MSTECH, devem ser cadastrados com a criticidade Moderado.