Como documentar testes funcionais?
Os testes de software devem ser documentados, sendo os testes funcionais um conjunto de passos feitos por um utilizador para validar as regras de negócio, as regras de design, usabilidade, entre outras. Identificam-se os vários cenários de teste que se considerem críticos para aceitação das funcionalidades, descreve-se o resultado esperado para cada um, o resultado obtido, os dados de testes e a data e hora em que foram feitos.
No decorrer dos testes podem identificar-se erros e melhorias, que devem ser reportados com o máximo de informação possível para que a equipa consiga analisar e resolver. Após resolução, é validado e deve atualizar-se com o novo resultado.
Este guia apresenta um conjunto de sugestões para que a documentação dos testes seja feita de forma coerente e fácil de partilhar com os vários membros da equipa.
Escrever casos de teste
O primeiro passo é identificar quais os diferentes cenários que vão ser testados. Dado que não se pode testar todos os cenários possíveis, é importante identificar os cenários críticos para o funcionamento correto do software. Estes são os casos de teste que devem ser escritos no caderno de testes.
Há várias formas de identificar os casos de teste, mas recomenda-se que seja feito com base nos requisitos funcionais. Uma forma simples é começar pelo "caminho feliz", isto é, o utilizador faz uma tarefa sem sair do fluxo que foi pensado - como por exemplo preencher um formulário corretamente, sem se enganar, e submeter no fim. Este é o cenário que representa o propósito principal da funcionalidade, e é preciso garantir que tem o comportamento esperado. A partir deste caso de teste, identificam-se outros cenários que se desviam do que seria o comportamento expectável do utilizador, e que possam causar problemas para o utilizador ou para o sistema. São cenários que testam os limites. Por exemplo, considerando um formulário que que apresenta uma opção de preenchimento apenas para utilizadores acima de 18 anos, devem ser testados, no mínimo, três cenários: utilizador com menos de 18 anos, idade igual a 18 anos e idade superior a 18 anos. Esta lógica deve ser aplicada aos vários requisitos de negócio. Cada requisito de negócio deve ter, pelo menos, um teste associado.
No template disponibilizado neste guia, a primeira tab apresenta um exemplo de preenchimento de casos de teste para uma funcionalidade de login, meramente exemplificativa. Cada caso de teste deve incluir os seguintes elementos:
ID: Número que identifica o caso de teste;
Caso de teste: Breve descrição que dê a entender qual o cenário de teste;
Passo-a-passo (opcional): Descrição detalhada da sequência de tarefas que devem ser feitas para fazer o caso de teste, podendo incluir dados de teste nesta descrição;
Resultado esperado: Descrição do resultado que se pretende obter com o teste;
Resultado obtido: Descrição do resultado após executar o teste. Caso não tenha sido o resultado esperado, é necessário reportar o erro (ou erros) com detalhe. A funcionalidade pode ter o comportamento esperado mas, ainda assim, identificar melhorias. Estas também devem ser reportadas com detalhe. Recomenda-se que seja criada uma lista à parte com todos os erros e melhorias (tab Problemas reportados);
Estado: Indica se o teste passou, falhou, ficou pendente (bloqueado) ou sem efeito, no caso de se perceber que afinal não era aplicável;
Última atualização: Data de quando foi testado. Após correção deve testar-se de novo e atualizar a data.
Comentários (opcional): Comentários que podem dar mais informações sobre o teste.
A gestão de testes pode ser feita com recurso a softwares e aplicações adequados para tal, que permitam distribuir os casos de teste por vários utilizadores ou testers, e reportar os erros e melhorias. Estas ferramentas permitem fazer um rastreamento de casos de teste por requisito, erros e melhorias, pois tudo está ligado. Em alternativa, o template excel pode ser uma solução, pois é importante documentar os testes que são feitos ao software de forma estruturada e com uma visão transversal para toda a equipa.
Reportar erros e melhorias
No decorrer dos testes são detetados problemas que podem ser classificados de erros ou melhorias. Considera-se um erro o comportamento do sistema diferente do esperado, isto é, diferente do que estava especificado nos requisitos de negócio. Uma melhoria surge quando, no decorrer dos testes, se verifica que o comportamento esperado não é o mais adequado à necessidade de negócio, ainda que funcione corretamente, deve ser alterado para servir melhor o seu propósito. Esta classificação é útil na gestão de âmbito de projetos de software, em particular os de âmbito fechado ou em período de garantia, bem como manutenção corretiva e evolutiva.
No template disponibilizado neste guia, a segunda tab apresenta um exemplo de problemas reportados após testar uma funcionalidade de login, meramente exemplificativa. Cada problema reportado deve incluir os seguintes elementos:
ID: Número que identifica o problema;
Teste: Número que identifica o caso de teste onde se detetou o problema reportado;
Tipo: Classificação (erro ou melhoria);
Descrição: Descrição detalhada do problema, de preferência com as seguintes informações:
Ambiente onde ocorreu;
Ecrã(s);
Passo-a-passo;
Data e hora;
Mensagens de erro obtidas;
Screenshots dos resultados. Quanto mais informação estiver na descrição do problema, mais fácil será a análise e resolução por parte da equipa.
Prioridade: Classificação da prioridade do problema entre baixa, média, alta e urgente;
Estado: Estado em que se encontra o problema, podendo classificar como (a lista seguinte é uma sugestão de classificações possíveis, mas deve ser adaptado às necessidades da equipa):
Novo: Problema reportado por analisar;
Em progresso: Problema em análise/resolução;
Corrigido: Problema resolvido, por validar;
Reaberto: Ao validar a correção, se o problema persistir deve ser reaberto;
Validado: Ao validar a correção verifica-se que o problema está resolvido.
Data reportado: Data de quando o erro foi reportado, de preferência com a hora em que ocorreu o erro também.
Data última atualização: Sempre que existir uma atualização deve ser registada a data;
Comentários: Comentários que podem dar mais informações sobre o problema.
A gestão de problemas (ou issues) pode ser feita com recurso a softwares e aplicações adequados para tal, que permitam distribuir os probelmas pelos membros da equipa para que possam analisar e corrigir. Estas ferramentas permitem fazer um rastreamento dos problemas reportados e da resolução ao longo do tempo. Em alternativa, o template excel pode ser uma solução, pois é importante documentar os problemas que são identificados ao fazer testes de software. Cada tab com um número identifica um problema reportado onde se pode adicionar mais detalhe com screenshots e outras informações que sejam úteis na análise e resolução dos problemas.
Last updated