Padrões para classificação de bugs

Versão 2.0 de 10/03/2017

Introdução

Com o amadurecimento do processo de testes na MSTECH, surge a necessidade da implantação de métodos de melhoria contínua da qualidade. Os bugs representam muito mais do que descritivos de falhas. Através de uma análise estatística, podemos identificar padrões de defeitos e, dessa maneira, sugerir melhorias e planos de ação para diminuir essas ocorrências, aumentando a qualidade dos produtos desenvolvidos. A classificação dos bugs auxilia nesse processo, dando aos gestores os instrumentos necessários para identificar esses padrões.

A versão 2.0 deste documento revisa as classificações de bugs com base na experiência adquirida pela equipe de testes, visando tornar as classificações mais claras, rápidas e precisas.

As principais mudanças são:

• Remoção da subcategoria: Teremos apenas um campo para indicar a classificação do bug. Todas as opções ficarão no campo Categoria. Essa mudança corrige uma limitação da ferramenta Youtrack, que não filtrava a subcategoria pela categoria selecionada.

• Remoção de categorias que não são utilizadas: A categoria Integração foi removida. Há uma limitação para identificar quando um bug foi gerado por problemas de integração de outras partes do sistema.

• Adição de novas categorias: Novas categorias foram adicionadas para refletir os tipos de bugs identificados no processo de desenvolvimento.

• Remoção do campo Origem: O campo Origem visava identificar bugs que são gerados em desenvolvimento, bugs que são encontrados na homologação e bugs que vêm da produção. O problema é que os bugs de homologação são corrigidos sem o registro de bugs no Youtrack e os bugs de produção entram como requisitos para as próximas sprints.

• Adição de Reasons: As Reasons permitem identificar quando um bug foi deferido, quando o desenvolvedor não consegue reproduzir ou quando um bug está obsoleto. Isso permite gerar métricas mais confiáveis para o processo de desenvolvimento e de testes.

Categorias

Construção

Utilizada quando o desenvolvimento introduziu defeitos no software, que causam falhas ou qualquer outro problema nas funcionalidades.

Exemplo 1:

Requisito: Página de cadastro de pessoas, com os campos Nome, Endereço e Telefone.
No teste: Os campos foram criados, porém não está salvando o campo Nome.

Neste caso, provavelmente não foram inseridos os métodos para salvar os dados do campo Nome.

Exemplo 2:

Requisito: Página de cadastro de pessoas, com os campos Nome, Endereço e Telefone.
No teste: Ao clicar no botão Salvar, sistema exibe mensagem de erro.

Neste caso, sistema apresentou uma falha, provavelmente por erro no código.

Definição

Ocorre quando:

• Determinada implementação não consta no requisito, mas é necessária para o desenvolvimento do sistema;

• O requisito não fornece informações completas sobre o que deve ser desenvolvido ou sobre todas as alterações necessárias;

• O requisito não especifica regras de negócio importantes para o desenvolvimento;

• O requisito contém informações erradas relacionadas ao sistema.

Um bug de definição deve ser direcionado ao analista de requisitos ou responsável pelo projeto, para as adequações necessárias.

Exemplo 1:

Requisito: A página deve conter filtros por Série e, em seguida, por Turma.
No desenvolvimento: Para que o requisito seja completado, o desenvolvedor precisou adicionar também o filtro por Escola para conseguir implementar os filtros por Série e Turma.

Ao identificar que o filtro Escola foi implementado e não consta no requisito, o testador deve procurar o desenvolvedor. Após esclarecer a necessidade, o testador deverá abrir um bug de Definição para que o analista de requisitos ou responsável pelo projeto corrija o requisito.

Exemplo 2:

Requisito: Implementar um serviço de fila para ser utilizado nos registros do fechamento do ano letivo das escolas.
No desenvolvimento: A fila foi implementada para a tela principal de lançamento, porém foi identificado que outras telas de lançamento também deveriam gerar fila.

O requisito deveria contemplar todos os lugares de implementação da fila.

Desacordo com o requisito

Essa classificação deve ser utilizada nos casos em que o sistema, módulo ou página não foi desenvolvido de acordo com os requisitos fornecidos. Também se aplica quando o requisito foi desenvolvido de maneira incompleta.

Exemplo:

Requisito: a página de cadastro de pessoas deve possuir os campos Nome, Endereço e Telefone.
Desenvolvimento: A página foi desenvolvida com os campos Nome e Endereço.

Vale lembrar que a página pode estar funcionando corretamente com os campos que foram implementados, porém a falta de um dos campos especificados no requisito caracteriza um problema.

Ortografia e gramática

Utilizada quando existem palavras, frases ou textos que não estão corretos com base na norma culta da língua.

Exemplo 1:

Texto: O período de cadastro deve ser de 01/01/2016 à 30/01/2016.

Nesse caso, não há crase.

Exemplo 2:

Texto: Não é possível realizar o cadastro pois não está dentro do prazo definido.

Nesse caso, deveria haver uma vírgula antes da conjunção “pois”.

Layout

Utilizada para bugs que reportam problemas no layout dos sistemas, como por exemplo:

• Desalinhamentos

• Layout quebrado em diferentes resoluções de tela

• Layout quebrado por diferenças em navegadores

Acessibilidade

Utilizada para bugs relacionados com funcionalidades de acessibilidade, como por exemplo:

• Alto contraste

• Tamanho de fontes

• Tooltips

• Navegação com a tecla TAB

• Navegabilidade sem mouse

• Textos dos links

• Leitor de tela

Padronização

Utilizada quando um requisito foi desenvolvido fora do padrão do sistema. Também quando o sistema ou parte do sistema está fora do padrão ou normas definidas pela MSTECH.

Exemplo:

Padrão do sistema: Todo título de página deve ter apenas a primeira letra maiúscula.	
Desenvolvimento: O título da página foi criado como “Cadastro de Alunos”.

Esse caso caracteriza um bug de conformidade, pois o nome da página deveria ser “Cadastro de alunos”.

Usabilidade

Utilizada quando o fluxo de uso de uma página está confuso ou pode causar dificuldades de entendimento por parte do usuário. Mensagens de validação ou de ajuda que estão mal escritas podem confundir o usuário. Esse tipo de problema entra na categoria Usabilidade.

Exemplos:

• Textos escritos com a gramática correta, mas com interpretação difícil;

• Mensagens que podem ser entendidas de maneiras diferentes;

• Fluxos de trabalho que apresentam barreiras (aspecto da interface no qual o usuário esbarra sucessivas vezes);

• Fluxos de trabalho que apresentam obstáculo (aspecto da interface no qual o usuário esbarra e aprende a superar);

• Fluxos de trabalho que apresentam ruídos (aspecto da interface que, sem se consistir em barreira ou obstáculo ao usuário, causa uma diminuição de seu desempenho na tarefa).

Performance

Utilizado quando o usuário identifica problemas de performance.

Exemplos:

• Consultas demoradas;

• Timeouts;

• Problemas identificados nos testes de performance.

Melhoria

Utilizado para o cadastro de melhorias no sistema. As melhorias devem ser aprovadas pelos responsáveis pelos projetos antes de serem executadas.

Reasons

Um bug pode mudar de situação por diversas razões. Quando o desenvolvedor muda a situação do bug para “Submetido”, não quer dizer que o bug foi resolvido. O bug pode ter sido adiado, estar obsoleto ou o desenvolvedor não conseguiu reproduzi-lo. Para auxiliar a identificar esses casos, existe o campo Reason.

Reason ou Motivo é um campo auxiliar na classificação de bugs. As reasons indicam os motivos pelos quais houve uma mudança de situação de um bug (Não iniciado, Em progresso, Submetido, Finalizado).

As reasons permitem gerar métricas de bugs mais confiáveis, contribuindo não só para a melhoria da qualidade dos produtos, mas também para a melhoria da equipe de testes.

Permitem saber:

• Quando um bug é novo;
• Quando um bug foi submetido por estar corrigido;
• Quando um bug foi submetido por não ter conseguido reproduzir;
• Quando um bug foi submetido por ser obsoleto;
• Quando um bug for submetido por ser adiado;
• Quando um bug for reaberto.

Novo

É a opção padrão. Quando um novo bug é cadastrado, seu motivo padrão é “Novo”.

Situação	Status do bug	Reason
Tester cadastra um bug	Não iniciado	Novo

Corrigido

Indica que o bug foi movido para a coluna Submetida do board, pois o problema foi corrigido.

Situação	Status do bug	Reason
Desenvolvedor corrige o bug	Submetido	Corrigido

Reaberto

Indica que o tester retestou o bug e identificou que o problema não foi corrigido.

Situação	Status do bug	Reason
Tester retesta o bug e identifica que o problema não foi corrigido	Não iniciado	Reaberto

Não foi possível reproduzir

Indica que o desenvolvedor não conseguiu reproduzir o bug seguindo as instruções passadas pelo Tester.

Situação	Status do bug	Reason
Desenvolvedor não consegue reproduzir o bug.	Submetido	Não foi possível reproduzir

Adiado

Indica que o bug foi despriorizado pelos responsáveis do projeto e será corrigido futuramente.

Situação	Status do bug	Reason
Bug será adiado		Adiado

Não é bug

Utilizado quando o usuário identifica que o item não é um bug.

Exemplos:

• O ambiente estava desatualizado;
• A documentação estava desatualizada;
• Tester teve um entendimento errado do requisito.
• Falta de configuração.

Situação	Status do bug	Reason
Tester ou desenvolvedor identifica que a situação não é um bug	Finalizado	Não é bug