Sobre

sexta-feira, 27 de março de 2015

Cuidado! Caso de teste pode levá-lo a cegueira.

Dois conceituados testers Katrina Clokie e Aaron Hodder testaram uma teoria para destacar a cegueira por desatenção que pode ocorrer durante a execução de casos de teste com script.

O conceito era simples. Eles escreveram um conjunto de oito casos de teste detalhados que instruem o testador em verificar se a função de ordenação de um site de compras funcionava como deveria. Cada testador (ou par de testers) tiveram exatamente o mesmo conjunto de oito casos de teste, idêntico em todos os detalhes. Deram 20 minutos para executá-los e após a conclusão, pediu-lhes o número de bugs que haviam encontrado, bem como o número de testes que tinha passado, que não passaram ou que não foram feitos.

O resultado mostrou que, quando pedimos diferentes pessoas a seguir os mesmos casos de teste, acabamos recebendo muitos resultados diferentes.

Alguns grupos não encontraram bugs. Um grupo encontrou cinco. A maioria encontrou dois bugs, mas com base na discussão subsequente estes não eram necessariamente os mesmos dois bugs. O mesmo fenômeno ocorreu quando os testadores foram convidados para alocar passe preto ou branco / reprovação adjudicação para seus testes. Em alguns casos, a presença de erros parecia resultar no caso de teste que falha. Em outros, o testador identificou um bug, mas ainda sentia que o teste tinha passado.

Para mim, isso destaca duas coisas realmente importantes.

A primeira é a cegueira por desatenção que pode ocorrer durante a execução de casos de teste. Este é o fenômeno que ocorre quando você está a se concentrar em uma coisa específica, isso significa que é provável que você perca outras coisas que podem estar acontecendo bem na frente de seus olhos. O exemplo mais famoso é o ” business ilusão macaco “.

Nesse exercício, e na execução de testes de scripts, cegueira por desatenção significa que uma vez que o procedimento documentado está focando sua atenção em uma linha específica de investigação, você está sujeito a perder erros ou comportamentos interessantes que ocorrem em torno das funções que o script especificamente destaca. Quero destacar isso para os testadores que estão lendo esse artigo fiquem cientes da falibilidade do método e podem fatalmente se desfocar regularmente durante a execução de um caso de teste, perdendo de encontrar bugs importantes.

Os casos de teste não refletem verdadeiramente o esforço cognitivo e temporal dos testes que ocorreram, em vez disso, ele reduz esse esforço  tornando todos equivalentes.

Em segundo ficou expresso também o perigo inerente de casos de teste e o nível implícita de equivalência que representam. Um grande número de testadores alegremente informaram sobre seus testes através da contagem do número de testes que passaram e o número que falhou. Esta é uma maneira extremamente redutora de representar uma informação que o teste deveria estar fornecendo, através da representação de todos os casos de teste como iguais

Tive um coordenador da Qualidade que sempre dizia muito empolgado ” Por que um dia, vamos especificar casos de teste para os implementadores” ele achava isso a solução de todos os problemas com bugs, mas desde aquela época eu já ficava com a pulga atrás da orelha e isso acabou se confirmando tempos depois, claro que dentro do meu contexto, não podemos de forma alguma generalizar. Mas isso me faz pensar se realmente especificar casos de teste para desenvolvedores é um bom negócio, já que eles poderiam ser presas fáceis para cegueira por desatenção, isso pode explicar também a dificuldade que alguns desenvolvedores tem em testar uma implementação com base na especificação e até mesmo alguns testadores. Modelos mentais e testes pareados podem ser de grande ajuda contra a cegueira por desatenção, além de economizar um tempo absurdo, que seria usado para escrever massantes casos de teste.

Muitos testadores  elaboram casos de teste como uma forma de demonstrar sua produtividade, apresentando ao final de cada sprint o número de casos de teste que passaram e por ai vai, números que não dizem absolutamente nada, muitos gerentes e coordenadores são culpados nisso, pois tatuaram em suas mentes que a forma de medir a produtividade de um testador é através do número dos casos de teste e acabam impondo essa farsa, isso quando não vem de consultores de teste terceirizados.

É uma cultura que se alastrou e que ainda vai permear por muito tempo. Se você como testador aceita isso passivamente e acha que teste de software se resume a casos de testes que comparam um resultado esperado com o resultado final, não se ache no direito de reclamar do seu salário, da falta de interesse do seu coordenador e desenvolvedores no seu trabalho na equipe.

Os casos de teste podem fazer parte do teste, assim como as inúmeras técnicas e ferramentas que nos auxiliam, mas jamais podem ser encarados como um teste por si só. Em vez se ficar no país das maravilhas com seus casos de testes, mostre aos seus colegas de equipe como os mapas mentais podem facilitar a construção de bons testes,  realize testes pareados com o intuito de demonstrar e ensinar testes com qualidade, use heurística, testes baseados em sessão, demonstre sua experiência adquirida ao longo do tempo como testador para encontrar bugs importantes de forma rápida, essa é uma das formas de demonstrar como você é um testador diferenciado e que realmente agrega valor dentro da equipe.