Post

1 Star2 Stars3 Stars4 Stars5 Stars

By José Carréra
Contribuir para o aumento do nível de confiança, prevenir e encontrar defeitos estão entre os principais objetivos que queremos alcançar quando testamos um software. Porém, para atingirmos essas metas não existe uma simples receita de bolo e precisamos estar sempre atentos para maximizar as nossas chances de entregarmos constantemente software de qualidade e que atenda às necessidades dos clientes.

Apesar de nossos esforços, invariavelmente temos que lidar com os defeitos escapados, que normalmente implicam em stress, re-trabalho e desgaste na relação com o cliente. Em meio ao problema, uma das primeiras ações que temos é a análise da causa raiz, ou seja, identificar o porquê do defeito ter ocorrido e consequentemente do mesmo não ter sido identificado nas etapas anteriores de validação.
Diversos podem ser os motivos para a falha na detecção do defeito, por exemplo:
– Cenário de teste não estava coberto.
– Teste existia, mas não foi priorizado para o ciclo de execução.
– Teste existia, foi priorizado, porém não foi executado corretamente.
– Teste existia, foi priorizado, executado corretamente, porém diferenças de ambiente não permitiram a detecção da falha.
– Etc.

Porém, ainda há um outro motivo, que talvez seja um dos mais frustrantes – O teste existe, mas está errado.
Quando isso acontece, independente de planejarmos corretamente, o teste, seja ele manual ou automático, nunca nos trará o resultado correto e a falha inevitavelmente aparecerá em produção. Nesses casos, ainda temos como dificuldade adicional o fato de que a re-execução do nosso teste não ajudará na reprodução do erro, podendo inclusive gerar ruído na comunicação e dificuldades na identificação da causa do problema e consequentemente em sua correção.
Identificar testes com defeito não é algo simples e corremos o risco de executá-lo diversas vezes e confiarmos em resultados enganosos. Para tentar minimizar esse tipo de situação, podemos realizar algumas ações:
– Revisar os testes existentes
– Se forem testes manuais, mudar o responsável pela execução
– Aprofundar-se no funcionamento de mocks e stubs utilizados para teste
– Conhecer as limitações das ferramentas utilizadas
– Revisar as pré-condições e o ambiente de validação
E você já enfrentou o problema de ter falhas escapadas devido a testes defeituosos? Que ações tomou para tentar evitar que o problema se repetisse?
Arquivado em:Testes de Sw

Source: http://bytesdontbite.com/2013/07/29/o-que-fazer-quando-o-defeito-esta-no-teste/

Category: Testes de Sw, bugs, casos de teste, cenários de teste, confiabilidade, defeitos, software, testes de software

Você também pode querer ler

Comments are off for this post.