casos de teste

Entre os dias 11 e 13 de Agosto aconteceu em Nova York a nona edição do CAST 2014(Conference of the Association of Software Testing). A conferência voltada inteiramente para a área de Testes de Software contou com a participação de diversos palestrantes discutindo e compartilhando informações e experiências referentes aos mais diversos tipos de problemas e práticas aplicadas na indústria.

Os vídeos das palestras já estão disponíveis no canal da associação no youtube. Na lista de palestras várias me parecem bem interessantes, particularmente, optei por começar pelo Keynote realizado pelo James Bach, autor de diversos livros na área, com tema Test Cases are Not Testing: Toward a Performance Culture. Apesar de não ser um tema novo, debater sobre como devemos usar os casos de teste ou mesmo se devemos usá-los, ainda é algo que rende muitas discussões. No vídeo, James faz diversas comparações bem interessantes e que reforçam o erro que é tratar testes de software como uma simples aplicação de passos de um caso de teste.

“We’ve got to stop thinking of testing as a thing and start thinking about testing as a performance, like an actor in a play, in order to get management to appreciate what we do.”

Divirtam-se!

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.

You are doing it wrong

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?