Post

1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

By Luiz Gustavo Schroeder Vieira Para seguir na fase de Test Analysis, é importante lembrar que os cenários macro de teste já foram criados. Agora é detalhar como estes cenários serão testados. Inclusive esta fase às vezes pode estar atrelada a fase de Test Execution, o que se transforma numa grande salada de fruta se o sistema estiver fora de controle.Parece que estou escrevendo o ciclo de desenvolvimento de testes (plano de teste, caso de teste, etc.) tudo de novo, né? Na verdade a resposta é sim, tudo tem uma relação. A ideia é oferecer uma nova visão de como dar manutenção nos casos de teste propriamente ditos, e não em todas as atividades de teste em geral. Por exemplo, se esse caso de teste possui um pré-requisito que deve ser cadastrado em outra tela, faça-o direto no banco (com suas devidas validações). Dai pode ter gente que vai perguntar: mas não vai testar de forma apropriada o cadastro dessa outra tela, os dados vão ficar viciados! Sim, resposta certa. Todavia a ideia é que a manutenção dos casos de teste sejam feitas no sistema inteiro (tanto no anterior como no atual).Quem nunca ouviu a frase: “esse sistema até meu priminho de quatro anos testa.”?concordo, qualquer um testaria. Todavia é importante levar em consideração que os sistemas crescem e podem, de certa forma, perder o controle. Geralmente as pessoas só se dão conta da importância de criar os casos de teste quando se perde o controle do sistema (ou às vezes nem isso). Esse controle de cada atividade deve ser feito de forma evolutiva, principalmente no início onde a cara do sistema geralmente é mais nebulosa.Nessa etapa do projeto, Test Analysis/Implementation, é onde os casos de teste não são só criados, antes da criação destes tem alguns itens bem críticos que serão cruciais para as próximas fases, como por exemplo: qual técnica será utilizada. Por exemplo, esses dias um colega me abordou perguntando como utilizar Pairwise Testing (ou Array Ortogonal). Perguntei a ele qual era o motivo pelo qual ele tinha escolhido a técnica. A intenção bem como a forma de abordar o desafio foram boas, ele decidiu por utilizar uma excelente técnica, mas o motivo pelo qual esta técnica foi escolhida (técnica que geralmente é utilizada para configurações, evitando as “combinações explosivas”. Tais como 3x5x4x2 = 120 casos de teste) não atendia às necessidades do caso de teste.Mas não só a utilização da técnica é um fator a ser levado em consideração, outro fator muito importante é definir a amarração dos casos de teste (test harness). O que seria isto? Bom, amarração dos casos de teste seria, em poucas palavras, definir a “rastreabilidade dos casos de teste”, quais testes são pré-requisitos uns dos outros, quais dados devem ser criados para iniciar cada caso de teste, etc. Uma boa prática é não atrelar o resultado de um caso de teste ao pré-requisito de outro. Como assim? Por exemplo, vamos criar um cliente chamado João no meu sistema (TC1) e na tela de compra do produto utiliza o usuário do João para efetuar a compra (TC2). Perceba que o João é o output de um caso de teste e o input do outro? Sim, geralmente isso dá problema – levando em consideração que o TC1 pode falhar por algum motivo, vai impedir a execução do TC2 – e por esse motivo, é melhor criar o dado diretamente na base, e não no sistema.Essa é a etapa crítica do Ciclo de Desenvolvimento dos Casos de Teste. Esse refinamento dado, tanto na questão técnica (detalhar o caso de teste) quanto na questão gerencial (definir qual teste é a sequência de execução), é muito delicado e não funciona da maneira correta com equipes juniores. Pois geralmente testadores menos experientes tem dificuldade de criar um caso de teste em tempo hábil, respeitando um cronograma de análise e implementação (há exceções).

Source: http://www.testavo.com.br/2011/07/test-case-lifecycle-test.html

Você também pode querer ler

Comments are off for this post.