O que fazer quando o defeito está no teste ?

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?

Anúncios

7 comentários sobre “O que fazer quando o defeito está no teste ?

  1. A análise de mutantes é uma estratégia presente na literatura para a avaliação de conjuntos de casos de teste. Nela, operadores de mutação são definidos e estes geram versões “mutantes” do sistema a ser testado.

    Com um determinado conjunto de casos de teste passando, ou seja, aprovando um certo sistema, a ideia é ter um conjunto de casos de teste que, além de passar para a versão não “mutada”, falhar quando executar sobre um mutante, matando-o.

    É bem viável a inserção da análise de mutantes no contexto do desenvolvimento de sistemas. Poderia ser realizada após uma iteração de teste de integração, coletando métricas de “mutantes mortos”, com o objetivo de ter muitas mutações (o máximo possível) e o máximo de mutantes mortos!

  2. Olá João!

    Gosto da técnica de “Injeção de Falhas” não mencionada no artigo.
    É algo simples que também resolve o problema em questão.

    Trata-se de um acordo prévio onde o programador insere um determinado número de erros conhecidos apenas por ele na aplicação.
    A suite de teste deve ser capaz de detectar no mínimo os erros inseridos propositalmente pelo programador.

    Caso os erros não sejam detectados, está evidente que a análise precisa ser revista.

    Abraços,
    Eduardo Souza

    • Parece com o princípio dos mutantes, com a diferença que o operador de mutação é o próprio programador! Esses operadores são algo como:

      – ir em um comando condicional e trocar ‘>’ por ‘<='
      – num comando iterativo, trocar 'i++' por 'i–'
      – algo mais elaborado ou relacionado com o domínio da aplicação

      A abordagem manual é mais pontual em alguma desconfiança, mas não consegue escalar bem, ou seja, gerar muitas variações e ver o que acontece. Já uma análise de mutantes, como manda o figurino, pode ser feita automaticamente, e depois apenas coletar os resultados, gerando milhares de versões mutantes do SUT (system under test).

      Com o resultado, dá pra saber quais testes são mais problemáticos (os que não matam mutantes ou matam poucos) e quais são os que matam mais mutantes!

      • Parece mesmo!

        A análise de mutantes é uma excelente técnica para testes unitários, onde a variação dos operadores lógicos é apenas uma das dezenas de mutações possíveis, mas explora as características das unidades separadamente.

        A implementação é muito parecida. A diferença é que na injeção de falhas o programador não se preocupa com todas as variações necessárias. Até por que todas as variações necessárias inviabilizaria o andamento dos testes. São casos bem específicos.

        Acredito de ambas sejam eficazes, porém cada uma no seu contexto.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s