Podemos testar para conhecer (testes exploratórios), podemos testar para verificar a qualidade de um produto já pronto e validar se ele atende às expectativas para que seja comprado ou ainda, acredito que o mais comum, podemos testar softwares antes de serem fechadas versões entregáveis dele ou como homologação para aceitar o produto.
Acredito que o principal resultado do trabalho de testes é o report de defeitos. A diferença entre o esperado e o atual. A reportagem incorreta de defeitos resulta na perda de valor da execução do teste.
Mesmo quando se está usando uma abordagem reativa de testes, e ainda não existem scripts, logue o defeito que você encontrar. Eles vão inclusive ajudar a criar esses scripts futuramente.
Que informações deve conter um log de defeito?
Bem, isso depende do contexto do seu projeto.
É fortemente recomendado que ele tenha um identificador único. Um número ou um código formado como convir que sirva como referência a esse erro.
Também é uma boa prática que ele tenha uma descrição sucinta, uma espécie de título (uma única frase) que indique em linhas gerais do que se trata o defeito.
Parece óbvio que a descrição do defeito é o mais importante, certo? Nessa descrição, procure especificar como se deu o defeito. Coloque um passo a passo, os dados que foram utilizados, tudo o que outra pessoa pode precisar para reproduzir novamente o erro encontrado. A propósito, procure informar nessa descrição a incidência desse erro (reproducibilidade), se com o passo a passo que você proveu é certo que ele vá ocorrer, ou se é um erro intermitente.
Informações como ambiente, versão do build, versão da documentação base (caso de teste, requisito, o que se aplicar), também são importantes. Lembre-se “a única constante da vida é a mudança” e se você não documentar essas informações, o seu defeito pode ser cancelado como se nunca tivesse existido e tivesse sido logado erroneamente. Não só como elemento de defesa, essas informações podem ser usadas para detectar instabilidade no ambiente, problemas de integração, erros de documento, ou mesmo para rastrear o defeito e a sua causa.
Para quem está gerenciando/acompanhando essa execução e as correções, é importante saber a severidade do erro encontrado. Esse parâmetro tem suas variações conceituais de empresa pra empresa. Um exemplo seria classificar com sev 1 um erro que impede que uma funcionalidade principal do sistema seja executada, sem workarounds; sev 2 um erro que impede que uma funcionalidade menos importante do sistema seja executada, sem workarounds; sev 3 um erro que não bloqueia a execução da funcionalidade, mas impacta no funcionamento correto, entretanto há um workaround para ele; sev 4 um erro sem grande relevância para a execução do projeto; sev 5 uma sugestão de melhoria. Reforço que esse é um exemplo qualquer e que essa definição varia de empresa para empresa, entretanto não deve variar de projeto para projeto. Deve ser um padrão da empresa e haver um entendimento uniforme do seu uso.
Outra informação útil é a prioridade. Isso vai dar um norte para a correção do erro. Na verdade quem pode ter mais insumos para opinar sobre isso pode ser o líder de desenvolvimento ao invés da equipe de testes. Imagine por exemplo que você está testando um módulo de um sistema de vários módulos dos quais você não tem tanto conhecimento de como anda o teste e há uma equipe de desenvolvimento integrada para resolver todos os erros reportados por todas as equipes de todos os módulos. O líder de desenvolvimento vai avaliando junto aos desenvolvedores a prioridade para correção desses erros e ele vai, provavelmente, ter muito mais conhecimento para determinar isso que você. Mas você pode dar uma idéia. Assim como a severidade, a prioridade deve obedecer a um padrão. Um critério para o teste estabelecer prioridades pode ser o número de casos de teste bloqueados ou impactados pelo defeito registrado.
A priorização da correção de um defeito deve então dar-se pela combinação de severidade e prioridade.
Em um time de teste é importante saber quem encontrou o defeito para se tirar dúvidas sobre ele, é importante saber a hora em que ele foi aberto para controlar o tempo de correção, é importante, se estão sendo utilizados casos de teste na execução, saber que caso de teste ‘desvendou’ o bug para que após sua correção o mesmo seja re-executado e que tipo é esse caso de teste (se manual ou automático).
É importante saber quem vai corrigir o defeito, ou melhor, quem está responsável pelo bug. A princípio ele pode ser designado para o líder de desenvolvimento e este selecionar quem no time dele ficará responsável pela correção ou designar direto para o desenvolvedor que fará a correção. Essa política também fica a cargo da empresa/projeto.
E por fim (o que não quer dizer que se esgotam as possibilidades), o defeito deve ter um status. Só essa informação já rende um post falando sobre máquinas de estado de defeitos.
Essas informações (e outras) podem ser encontradas no formulário padrão de abertura de defeitos das ferramentas de gerenciamento de execução de teste. Há várias free no mercado, mas é possível documentar os defeitos no Excel ou no Access, claro, com um gerenciamento dessas informações bem comprometido. Mas se você não tem ferramenta alguma e quer começar a documentar os defeitos encontrados no seu projeto, pode ser um começo.
Procure documentar qualquer coisa que atrase, interrompa, bloqueie ou interfira de alguma maneira na execução dos testes. Fica mais fácil controlar o que está acontecendo na execução e tomar medidas. Por exemplo: O banco de dados está fora do ar. Não é um defeito na aplicação, mas é um problema que deve ser logado e que ajuda a responder coisas como “quanto tempo a equipe de testes ficou parada e por quê?”, “que impacto teve a queda do banco na execução dos testes e conseqüentemente no cronograma do projeto?”
Ainda o report de defeito pode ser usado na avaliação do critério de saída da fase de testes, dependendo do que foi estabelecido no planejamento de testes, mas isso também é assunto para outro post.
Abaixo, uma telinha com o report básico de issues do Mantis. Note que ele contém poucas informações se comparado a todas as sugestões dadas aqui, mas lembre-se também de não colocar todas essas informações porque é bonitinho ter um report cheio de informações. Ao contrário, todas as informações registradas devem ser úteis e todos devem ter ciência da utilidade delas para que haja comprometimento e responsabilidade ao preencher essas informações. Fazer com que sejam informados dados que não serão utilizados caracteriza o processo de report de defeitos como burocrático e ao contrário, é talvez essa seja essência da produção do teste.
Nenhum comentário:
Postar um comentário