Processo de Teste: Implementação e Execução II

Continuando post Processo de Teste: Implementação e Execução, agora com foco maior em Execução.


Iniciando a execução dos testes

Para iniciar os testes, espera-se que os critérios de entrada para essa fase tenham sido atendidos e que esses critérios cubram o que foi discutido no post anterior.

Nessa fase, espera-se que todas as condições de teste e riscos de qualidade tenham sido cobertos e que todos os passos do procedimento de teste tenham sido executados. (...) E por que não seriam?

Como não cobrir as condições de teste e riscos de qualidade? Com testes em alto nível que dependem da interpretação do testador ou que exigem do testador maior conhecimento na aplicação.

Como não executar todos os passos? Alguns passos podem corresponder à configuração de dados, realização de pré condições, retorno do sistema ao estado inicial antes do teste, etc. Em algumas situações esses passos podem ser pulados resultando na execução parcial do teste.

Nos testes manuais pode-se adicionar um certo grau de testes exploratórios deixando o procedimento um pouco mais vago ou na orientação dos testadores explicando que o teste pode servir como um mapa, um guia do que tem que ser testado e que eles podem explorar essa área e investigar os pedaços que eles considerem mais interessantes.


Zoom: Executando um procedimento de teste

Ao executar um procedimento de teste o testador vai comparar o resultado obtido com o resultado esperado no teste e esse é o momento que realmente agrega valor. Tudo o que foi realizado até agora foi para chegar a esse momento, portanto o registro dessas anomalias é a parte mais importante de todo o processo. E falando em anomalia, vamos lá ao dilema das definições.

SEGUNDO O ISTQB: Um resultado obtido diferente de um resultado esperado é uma anomalia e ao a observarmos, temos um incidente. Até ai tudo bem? :) Alguns incidentes são falhas. Uma falha ocorre quando o sistema não se comporta adequadamente devido a um ou mais defeitos. Nesse caso podemos coletar dados e situações para ajudar os desenvolvedores a solucionar o defeito. Alguns incidentes podem não ser falhas mas falso positivos, ou seja, o resultado obtido foi diferente do esperado por má especificação dos testes, dados inválidos, ambiente mal configurado, etc.


Reportando resultados de testes

Maiores detalhes Reportando Defeitos
Não é possível usar o valor que você ganhou na realização dos testes se você não registrá-lo. Em estratégias de teste reativas, é possível usar os defeitos registrados para fazer um script ou mesmo como base de conhecimento da aplicação. No post acima eu listo alguns dados a serem incluídos nessa reportagem de defeitos.

É importante para o controle e gerenciamento do projeto reportar qualquer problema que atrase, interrompa ou bloqueie os testes. Por exemplo: Se na hora de começar os testes descobre-se que o ambiente está fora, está correndo o tempo de execução de testes e é impossível executá-los, é possível abrir um defeito de ambiente e o tempo de correção deve ser indicado com uma das justificativas de atraso (se houver) na execução.


Padrões

IEEE 829 test procedure specification. Esse documento especifica como rodar um ou mais testes e inclui as seguintes seções:

- identificador da test procedure

- objetivo (que testes serão rodados)

- requisitos especiais (permissões, habilidades, ambiente...)

- passos do procedimento (logar, configurar, executar os passos, medir os resultados, finalizar, recomeçar, parar, etc)

IEEE 829 também sugere o que colocar em um log de teste:

- identificador do test log

- descrição do teste (itens de tetse, ambiente, versões, etc)

- atividades e eventos de entrada

Outros padrões que sugiro que dêem uma lida: BS 7925/2 e DO-178B(ou ED-12B).