Política para registro de Bugs, Erros ou Defeitos¶
Registro de Bugs / Erros / Defeitos¶
Os seres humanos são propensos a falhas e, portanto, é crucial validar nossos sistemas para mitigar essas ocorrências. É importante observar que mitigar não é o mesmo que sanar. Assim, embora testar não garanta uma ausência total de problemas no sistema, contribui significativamente para minimizar suas ocorrências.
Olhando para os processos Almaviva, devemos seguir alguns processos quanto ao registros dessas inconsistências, conforme abaixo:
- Realizar plano de teste adequadamente;
- Realizar os testes seguindo cenários/critérios definidos;
- Após identificar um BUG , Erro ou Defeito, registrar como novo card na ferramenta na qual o time trabalha. Isso para o devido acompanhamento e gestão de qualidade;
- Após a abertura realizar o devido acompanhamento. É responsabilidade do Desenvolvedores (QA) fazer essa gestão;
- Assim que a correção for realizada, realizar os devidos re-testes. Vale ressaltar que não apenas o teste do cenário / critério deverá ser refeito, mas sim quando necessário também itens de regressão para avaliar possíveis consequências da correção implementada pelo Desenvolvedor. Isso garante que outras partes do sistema não tenha sido afetado pela correção;
- Caso o erro persista, deverá ser refeito todos os passos novamente até que a não exista mais o problema em questão;
- Caso tenha sido sanado, realizar as devidas movimentações na ferramenta de gestão e formalizações para transparecer para o time que o item foi corrigido. Isso também fará com que a gestão de indicadores de qualidade seja devidamente atualizado, trazendo uma visão da qualidade do projeto em questão.
Card de Bug, Erro ou Defeito¶
A falha encontrada deverá ser registrada como um novo card e associado a respectiva HU. Para separarmos em qual ambiente a falha ocorreu, é necessário realizar a devida classificação, sendo: Desenvolvimento = Bug; Homologação = Erro e Produção = Defeito.
Para isso, os seguintes campos deverão ser preenchidos obrigatoriamente:
-
Título: [Número do Ciclo] - [Nome da falha - Descrição utilizando o verbo no infinitivo]
- Títulos devem ser objetivos e significativos. Não devem ser extensos ou conter explicações que podem ser inseridas na descrição do item;
- O tamanho limite deverá ser de 100 posições considerando espaços em branco;
- Quando um BUG, Erro ou Defeito for inserido em um Ciclo, deverá ter como prefixo o código (CL) e numero do Ciclo onde a falha foi encontrada.
- Nome da Falha - Descrição utilizando o verbo no infinitivo
- Resultado final:
- CL001 - Realizar consulta de dados cadastrais diferente do esperado
-
Descrição: Descrever brevemente o ocorrido ou um título que represente o problema encontrado
- Etapas para reprodução: Descrever as etapas para reprodução do Bug, podendo ser um passo a passo ou um detalhamento de como o problema ocorre;
- Comportamento incorreto: Descrever o comportamento incorreto observado;
- Comportamento esperado: Descrever como a aplicação deveria se comportar;
- Logs e/ou capturas de tela: Anexar a evidência da falha e logs e/ou capturas de tela que sejam relevantes para o entendimento e resolução do Bug;
- Itens Vinculados: A tarefa e/ou card que deu origem a falha deverá ser associada com o novo card de Bug, Erro ou Defeito;
- LABEL: Inserir as labels associadas ao Tipo, Impacto e Probabilidade. Ver item abaixo "Classificação de Registro de Bugs, Erros e Defeitos".
Classificação de Registro de Bugs, Erros e Defeitos¶
Em complemento a criação dos registros de Bugs, Erros e Defeitos, temos as classificações dessas ocorrências. Essas classificações deverão ser inseridas nos devidos cards abertos dessas ocorrências. As labels utilizadas deverão ser as seguintes:
-
Tipos:
- BUG - falha identificada em Desenvolvimento
- ERRO - falha identificada em Homologação
- DEFEITO - falha identificada em Produção
-
Impacto:
- IMPACTO: Baixo - falhas simples que podem ser tratadas rapidamente, sem grande impacto na entrega planejada
- IMPACTO: Moderado - falhas que demandam mais tempo para solução e que podem acarretar riscos à entrega planejada
- IMPACTO: Alto - falhas que exigem mais tempo para resolução e representam um alto risco para o ciclo de desenvolvimento planejado.
-
Probabilidade:
- PROBABILIDADE: Baixa - refere-se a falhas com baixa probabilidade de recorrência, indicando que são eventos raros ou pouco frequentes
- PROBABILIDADE: Média - falhas com uma probabilidade média de recorrência, sugerindo que podem ocorrer ocasionalmente ou em certas circunstâncias
- PROBABILIDADE: Alta - falhas com uma alta probabilidade de recorrência, apontando para problemas que são frequentes ou que ocorrem regularmente durante o desenvolvimento
-
Causa da falha:
- CAUSA: Arquitetura - Refere-se a falhas causadas por problemas relacionados à arquitetura do sistema, como falhas de design ou de estrutura
- CAUSA: Requisito - Diz respeito a falhas originadas por inadequações ou ambiguidades nos requisitos do software, resultando em funcionalidades incorretas ou ausentes
- CAUSA: Implementação - Indica falhas derivadas de erros na implementação do código-fonte, incluindo erros, má lógica de programação ou problemas de codificação.
- CAUSA: Ambiente - Refere-se a falhas causadas por questões dos ambientes, como configurações incorretas de hardware ou software, dependências ausentes ou incompatibilidades de plataforma.
Fluxo de execução de BUGs, Erros ou Defeitos¶
Considerando as interações do QA e cada ambiente até produção:
ATENÇÃO: No processo de trabalho, quanto a movimentação de cards no Board, somente é possível movimentar para execução dos testes um item por vez. Isso para acompanhamento devido das tarefas em execução no momento e também para devida contagem de tempo dos itens. Para itens de re-testes, deverão ser inseridas novas evidências da nova execução do teste.