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

Versão 1.5 de 02/02/2017

Bugs funcionais

Crítico

Definição

Geralmente reservado para erros fatais. Indicam que o teste não pode continuar sem correção. Ocorrem quando há problemas frequentes que impedem o usuário de concluir uma história utilizando funcionalidade considerada principal e não há maneiras de contornar o problema. 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

Em relação à história do usuário:

1. Bugs que ocorrem sempre em funcionalidades principais 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 aplicaçã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. Condições de contorno (workarounds) complexos
5. Comprometimento moderado da continuidade dos testes

Em relação à história do usuário:

1. Em funcionalidade principal: Bugs que ocorrem sempre, mas o usuário possui ao menos uma alternativa para contornar.
2. Em funcionalidade principal: Bugs que ocorrem às vezes ou raramente, porém o usuário não consegue contorná-los.
3. Em funcionalidade secundária: Bugs que ocorrem sempre e que o usuário não consegue contornar.

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. Baixo impacto dos testes
3. Erros de ortografia/gramática

Em relação à história do usuário:

1. Funcionalidades principais: Bugs que ocorrem sempre, mas o usuário consegue realizar a tarefa sem impacto.
2. Funcionalidades principais: Bugs que ocorrem às vezes, mas existem alternativas para contorná-los.
3. Funcionalidades secundárias: Bugs que ocorrem sempre, mas existem alternativas para contorná-los.
4. Funcionalidades secundárias: Bugs que ocorrem raramente ou às vezes e que o usuário não consegue contornar.

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

Em relação à história do usuário:

1. Funcionalidades principais: Bugs que ocorrem raramente e o usuário consegue realizar a tarefa normalmente e/ou existem alternativas.
2. Funcionalidades principais: Bugs que ocorrem às vezes e o usuário consegue realizar a tarefa normalmente.
3. Funcionalidades secundárias: Bugs que ocorrem raramente, às vezes ou sempre, porém o usuário consegue realizar a tarefa normalmente.
4. Funcionalidades secundárias: Bugs que ocorrem raramente ou às vezes, mas existem alternativas para contorná-los.

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

Tabela Frequência/Gravidade de bugs funcionais

Observações

• Quando o bug for o próprio requisito ou parte dele, sua criticidade não pode ser baixo (entra como grave se não foi feito).

Bugs de usabilidade

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.

Inteligibilidade

Os bugs da subcategoria Inteligibilidade podem ser classificados usando como referência a tabela Abrangência/Impacto.

Para verificar o impacto de um bug na usabilidade, podemos classificá-lo como uma barreira, um obstáculo ou um ruído.

• Barreira: refere-se a um aspecto da interface no qual o usuário esbarra sucessivas vezes.

• Obstáculo: refere-se a um aspecto da interface no qual o usuário esbarra e aprende a suplantá-lo.

• Ruído: refere-se a um aspecto da interface que, sem se consistir em barreira ou obstáculo ao usuário, causa uma diminuição de seu desempenho na tarefa.

Para verificar a abrangência do bug, podemos classificá-lo em principal e secundário.

• Principal: um aspecto da interface que compromete a realização de tarefas frequentes ou importantes

• Secundário: um aspecto da interface compromete a realização de tarefas pouco frequentes ou pouco importantes.

Tabela Impacto/Abrangência de bugs de usabilidade - Integibilidade

Referências

• UFSC - O Ciclo da Engenharia da Usabilidade
• Resultados Digitais - Gestão de defeitos