Mudanças entre as edições de "Padrões para definição de criticidade de bugs"

De MSTECH wiki
Ir para: navegação, pesquisa
(→‎Bugs de usabilidade)
 
(35 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 1: Linha 1:
 +
Versão 1.5 de 02/02/2017
  
 
==Bugs funcionais==
 
==Bugs funcionais==
Linha 6: Linha 7:
 
====Definição====
 
====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.'''
+
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====
 
====Características====
Linha 15: Linha 16:
 
# Build da aplicação corrompido
 
# Build da aplicação corrompido
 
# Funcionalidades principais severamente comprometidas ou impossível de ser utilizada
 
# Funcionalidades principais severamente comprometidas ou impossível de ser utilizada
 +
 +
'''Em relação à história do usuário:'''
 +
# Bugs que ocorrem sempre em funcionalidades principais e que o usuário não consegue contornar.
  
 
====Exemplos de erros desse grau de severidade====
 
====Exemplos de erros desse grau de severidade====
Linha 34: Linha 38:
 
====Definição====
 
====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.'''
+
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====
 
====Características====
Linha 40: Linha 44:
 
# Funcionalidade periférica impossível de ser utilizada
 
# Funcionalidade periférica impossível de ser utilizada
 
# Sistema travando (dificulta o uso mas funciona)
 
# Sistema travando (dificulta o uso mas funciona)
−
# Bug em funcionalidade essencial do produto
 
 
# Condições de contorno (workarounds) complexos
 
# Condições de contorno (workarounds) complexos
 
# Comprometimento moderado da continuidade dos testes
 
# Comprometimento moderado da continuidade dos testes
 +
 +
'''Em relação à história do usuário:'''
 +
# Em funcionalidade principal: Bugs que ocorrem sempre, mas o usuário possui ao menos uma alternativa para contornar.
 +
# Em funcionalidade principal: Bugs que ocorrem às vezes ou raramente, porém o usuário não consegue contorná-los.
 +
# Em funcionalidade secundária: Bugs que ocorrem sempre e que o usuário não consegue contornar.
  
 
====Exemplos de erros desse grau de severidade====
 
====Exemplos de erros desse grau de severidade====
Linha 59: Linha 67:
 
====Características====
 
====Características====
 
# Problemas moderados em funcionalidades do produto
 
# Problemas moderados em funcionalidades do produto
−
# Gambiarra simples
 
 
# Baixo impacto dos testes
 
# Baixo impacto dos testes
−
# Ergonomia (usabilidade) razoavelmente comprometida
 
 
# Erros de ortografia/gramática
 
# Erros de ortografia/gramática
 +
 +
'''Em relação à história do usuário:'''
 +
# Funcionalidades principais: Bugs que ocorrem sempre, mas o usuário consegue realizar a tarefa sem impacto.
 +
# Funcionalidades principais: Bugs que ocorrem às vezes, mas existem alternativas para contorná-los.
 +
# Funcionalidades secundárias: Bugs que ocorrem sempre, mas existem alternativas para contorná-los.
 +
# 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====
 
====Exemplos de erros desse grau de severidade====
Linha 87: Linha 99:
 
====Características====
 
====Características====
 
# Não chega a comprometer o objetivo da funcionalidade
 
# Não chega a comprometer o objetivo da funcionalidade
−
#Afeta a aparência da funcionalidade
+
# Afeta a aparência da funcionalidade
 +
 
 +
'''Em relação à história do usuário:'''
 +
# Funcionalidades principais: Bugs que ocorrem raramente e o usuário consegue realizar a tarefa normalmente e/ou existem alternativas.
 +
# Funcionalidades principais: Bugs que ocorrem às vezes e o usuário consegue realizar a tarefa normalmente.
 +
# Funcionalidades secundárias: Bugs que ocorrem raramente, às vezes ou sempre, porém o usuário consegue realizar a tarefa normalmente.
 +
# Funcionalidades secundárias: Bugs que ocorrem raramente ou às vezes, mas existem alternativas para contorná-los.
  
 
====Exemplos de erros desse grau de severidade====
 
====Exemplos de erros desse grau de severidade====
Linha 107: Linha 125:
 
* Sugestão de termos.
 
* Sugestão de termos.
 
* Cores
 
* Cores
 +
 +
===Tabela Frequência/Gravidade de bugs funcionais===
 +
 +
[[Arquivo:gravidadefrequenciafuncionalprincipal.png]]
 +
 +
[[Arquivo:gravidadefrequenciafuncionalsecundaria.png]]
 +
 +
==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==
 
==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===
 +
 +
[[Arquivo:usabilidade.png]]
 +
 +
==Referências==
  
−
{| {{table}} class="wikitable"
+
*[http://www.labiutil.inf.ufsc.br/hiperdocumento/unidade3_3_1_1.html UFSC - O Ciclo da Engenharia da Usabilidade]
−
| align="center" style="background:#f0f0f0;"|
+
*[http://shipit.resultadosdigitais.com.br/blog/como-fazemos-gestao-de-defeitos-com-github Resultados Digitais - Gestão de defeitos]
−
| align="center" style="background:#f0f0f0;"|'''Criticidade'''
+
−
|-
+
−
!colspan="2"|Cores
+
−
|-
+
−
| Nenhum campo ou componente do formulário está fora do padrão de cor||Crítico
+
−
|-
+
−
| Textos digitados nos campos ou as informações dos componentes podem ser vistas normalmente||Crítico
+
−
|-
+
−
| Janelas popup estão no padrão de cor||Crítico
+
−
|-
+
−
| Marcações de campos obrigatórios ou mensagem podem ser vistas normalmente||Crítico
+
−
|-
+
−
| Logos ou imagens são visíveis normalmente||Crítico
+
−
|-
+
−
!colspan="2"|Layout
+
−
|-
+
−
| Todas as fontes estão no mesmo padrão||Grave
+
−
|-
+
−
| Botões devem estar no mesmo lugar em todas as páginas||Grave
+
−
|-
+
−
| Todos os componentes estão com o mesmo padrão de layout||Médio
+
−
|-
+
−
| Botões devem ter mesmo padrão de cor e tamanho em todos os lugares||Médio
+
−
|-
+
−
| Plano de fundo do site não pode distrair o usuário||Médio
+
−
|-
+
−
| Campo, botões e componentes da página devem estar alinhados corretamente||Médio
+
−
|-
+
−
| Possui o versionamento no rodapé das páginas||Grave
+
−
|-
+
−
!colspan="2"|Breadcrumb
+
−
|-
+
−
| Existem níveis de BrasdCrumb em todas as páginas||Grave
+
−
|-
+
−
| Links existentes na BreadCrumb levam para algum lugar específico e não uma opção aleatória do menu||Grave
+
−
|-
+
−
| Níveis da BreadCrumb estão escritos corretamente||Baixo
+
−
|-
+
−
!colspan="2"|Mensagens
+
−
|-
+
−
| Todas as mensagens deverão ser escritas como uma sentença normal de texto, com a primeira letra em maiúscula e as demais minúsculas, finalizando com um ponto final e com grande atenção a concordância. ||Médio
+
−
|-
+
−
| Devem ter um ícone identificador e uma mensagem informativa||
+
−
|-
+
−
| Mensagens de erro sobre a digitação incorreta ou informação inválida, deve falar qual a informação desejada ou o formato dela||Melhoria
+
−
|-
+
−
| Devem estar escritas corretamente||Baixo
+
−
|-
+
−
| O nome dos campos na mensagem de digitação incorreta corresponde ao label dos campo.||Grave
+
−
|-
+
−
| Entidade referenciada na mensagem deve estar correta||Grave
+
−
|-
+
−
| Mensagens devem estar alinhadas a esquerda||Médio
+
−
|-
+
−
| Ordem dos botões é Sim e Não||Crítico
+
−
|-
+
−
!colspan="2"|Cadastros
+
−
|-
+
−
| Existe alguma informação visual ou textual correspondendo ao bloqueio do campo||Médio
+
−
|-
+
−
| Existe uma diferenciação do campo bloqueado para alteração e bloqueado por outros motivos, como por exemplo, deve ser realizada uma busca||Médio
+
−
|-
+
−
| Existe alguma indicação do tipo de dado aceito por ele (quando o mesmo é uma informação restrita)||Médio
+
−
|-
+
−
| Deve haver uma diferenciação entre as opções de incluir e alterar (título, informação no formulário, etc)||Grave
+
−
|-
+
−
| Campos marcados como obrigatórios devem aparecer na mensagem de erro sobre preenchimento dos campos||Grave
+
−
|-
+
−
| Campos da mensagem de erro sobre obrigatoriedade devem estar marcador no formulário||Grave
+
−
|-
+
−
| Campos referente ao nome de alguma entidade, não devem estar escritos apenas "Nome"||Médio
+
−
|-
+
−
| Foco ao entrar no formulário deve estar no primeiro campo do formulário.||Baixo
+
−
|-
+
−
| Ordem dos botões de é Salvar e Cancelar||Grave
+
−
|-
+
−
| Botões devem estar alinhados a esquerda||Melhoria
+
−
|-
+
−
| Devem ter um feedback com relação a alteração, inclusão e exclusão dos registros||Crítico
+
−
|-
+
−
| Se for um cadastro em janela popup, a informação de cadastro deve existir na barra de título||Grave
+
−
|-
+
−
| Todos os campos e botões habilitados devem possuir texto de ajuda.||Melhoria
+
−
|-
+
−
| O botão Cancelar deve interromper o processo atual e voltar para a tela anterior||Crítico
+
−
|-
+
−
| Deve existir um botão para interromper o processo atual e voltar para o anterior||Crítico
+
−
|-
+
−
| Deve existir uma mensagem indicando o que significa a marcação dos campos obrigatórios, no início do formulário.||Grave
+
−
|-
+
−
!colspan="2"|Título do formulário
+
−
|-
+
−
| Deve ser compatível com a BreadCrumb||Médio
+
−
|-
+
−
| Deve estar escrito corretamente||Médio
+
−
|-
+
−
| Deve ser compatível com o menu||Médio
+
−
|-
+
−
| Título de cadastro devem estar no padrão Cadastro de entidade_X||Baixo
+
−
|-
+
−
!colspan="2"|Campos
+
−
|-
+
−
| Campos de data deverão assumir a máscara no formato dd/mm/aaaa||Grave
+
−
|-
+
−
| Campos de horário deverão possuir máscara no formato hh:mm||Grave
+
−
|-
+
−
| Campos de valores monerários deverão possuir uma máscara que defina pelo menos o formato 0,00; com duas casas decimais, com possibilidade de digitação de numeros apenas.||Médio
+
−
|-
+
−
| Campos de valores deverão estar alinhados a direita||Médio
+
−
|-
+
−
| Campos do tipo combo, salvo exceções, deverão possuir como primeira opção o texto para selecionar um campo.||Grave
+
−
|-
+
−
| Todas as opções do campo combo deverão estar ordenadas alfabeticamente de forma crescente||Baixo
+
−
|-
+
−
| Todos os campos de texto normal ou tipo combo deve serão ter seu tamanho definido, visando o tamanho que melhor acomode o conteúdo e não deixe a tela com diversos tamanhos de campos.||Baixo
+
−
|-
+
−
| Campo não devem trazer nenhuma informação pré-definida, fora casos estabelecidos anteriormente||Crítico
+
−
|-
+
−
| Em campo de datas, o componente de seleção não deve ficar com um dia especifico selecionado em todos os meses||Grave
+
−
|-
+
−
| Todos os campos apresentam a mesma fonte||Grave
+
−
|-
+
−
!colspan="2"|Grids e listagens
+
−
|-
+
−
| As colunas bloqueado e excluir, quando existirem, deverão ser as colunas mais a direita da grid;||Médio
+
−
|-
+
−
| As colunas com botões, imagens, textos curtos (sim/não) ou situações e outros pré-definidos deverão ter seu cabeçalho e seu conteúdo alinhados centralizados;||Baixo
+
−
|-
+
−
| As colunas com dados numéricos (monetários e outros) deverão ter seu cabeçalho centralizado e seu conteúdo alinhado a direita.||Baixo
+
−
|-
+
−
| Todas as colunas apresentam um título coerente para o seu conteúdo||Grave
+
−
|-
+
−
| Opção de exclusão deve fornecer uma mensagem confirmatória sobre a ação.||Crítico
+
−
|-
+
−
| Quando houver mais de uma listagem na mesma tela, caso a quantidade e os itens das colunas sejam semelhantes, o alinhamento deve permanecer, mesmo em tabelas diferentes.||Baixo
+
−
|-
+
−
!colspan="2"|Pesquisas
+
−
|-
+
−
|Pesquisas deveriam ter um feedback com relação ao processamento||Melhoria
+
−
|-
+
−
|}
+

Edição atual tal como às 13h07min de 9 de fevereiro de 2017

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

Gravidadefrequenciafuncionalprincipal.png

Gravidadefrequenciafuncionalsecundaria.png

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

Usabilidade.png

Referências

Disponível em "http://wiki.mstech.com.br/index.php?title=Padrões_para_definição_de_criticidade_de_bugs&oldid=4318"