Teste de Software: O Paradoxo do Pesticida

 A criatividade em criar casos de testes e a maneira como executamos os mesmos é o que diferencia o quão qualitativo ou repetitivos serão os próximos testes.

Revisar e modificar as escritas dos templates (quando for necessário) a cada início de projeto e/ou Sprint evita a perda de qualidade na execução dos testes e consequentemente evita a entrada em um estado conhecido como: O Paradoxo do Pesticida.

Pesticida, como assim?!

Eu vou explicar e você verá que tudo fará sentido depois.

Vamos partir do ponto, o que é Pesticida e para que ele serve:

O pesticida é uma substância química que é lançada em locais ou diretamente às pragas afim de evitar que as mesmas se proliferem, destruam plantações ou até mesmo disseminem doenças, incomodem pessoas e etc.

De acordo com pesquisas, se aplicarmos o mesmo pesticida várias vezes em um determinado local, os insetos que sobrarem serão imunes a ele, ou seja, a adaptação ao pesticida seria o resultado das transformações do seu organismo diante da necessidade, logo o pesticida tornaria os insetos resistentes ao invés de exterminá-los.

Você deve estar se perguntando: Mas o que isso tem a ver com a Área de Testes?

Assim como o pesticida perde sua eficácia com o passar do tempo, o mesmo ocorre na área de Testes. De acordo com Boris Beizer, aplicar e reaplicar não é um processo adequado para teste de software e a utilização de um mesmo conjunto de casos de testes constantemente para um determinado sistema, com o passar do tempo, ficarão menos qualitativas e eficazes como utilizado em sua primeira vez.

Quando não encontramos falhas, nem sempre é sinal de que não existem erros, mas porque a repetitividade dos casos de testes existentes em templates está criando o Paradoxo do Pesticida.

Caso os mesmos testes sejam replicados em constante frequência, em algum momento eles deixarão de ser úteis e consequentemente perderão sua qualidade, ou seja, não encontrarão novos defeitos e assim nos darão a falsa sensação de que o sistema não possui nenhuma falha, o que acaba se tornando perigoso pelo fato de que o sistema poderá ser entregue ao cliente final repleto de defeitos.

Devido à prática de sempre reutilizar casos de testes antigos, devemos sempre revisar os templates, atualizá-los constantemente e buscarmos novas formas de otimizá-los, uma ótima forma seria a prática do Pair Testing, onde dois testadores se reúnem para realizar levantamentos de cenários de testes e validar quais os casos válidos para determinado comportamento do sistema [você pode saber mais sobre essa prática clicando aqui], desse modo a análise dos cenários e a otimização dos mesmos serão menos complexas e assim a sua reformulação abordará novas funcionalidades do sistema de modo a aumentar a chance de detectar novas falhas e consequentemente manter o software com a qualidade esperada.

Referências:

https://sites.google.com/site/biologiaaulaseprovas/identidade-dos-seres-vivos/adaptacao-dos-organismos-a-diferentes-ambientes/adaptacao-a-inseticidas

http://www.sofist.com.br/artigo/a-praga-da-repetitividade

https://pt.wikipedia.org/wiki/Pesticida

http://www.devmedia.com.br/fundamentos-do-teste-de-software-para-certificacao-ctfl/30708

Por RAIANY DE ARAÚJO SILVA

Manauense morando há tempo suficiente para considerar Campinas como sua cidade do coração, iniciante e desde então buscando se aprofundar mais na área de Testes de Software.

Postado em: 06 de fevereiro de 2017

Confira outros artigos do nosso blog

Introdução ao Dev-Test Pairing

13 de junho de 2018

Caio Rizolli

Falando sobre Teste de Intrusão (ou PenTest)

03 de abril de 2018

Jacqueline Costa

Protractor – Testes automáticos end-to-end para aplicações em Angular

07 de dezembro de 2017

Jacqueline Costa

Testes em Node.js

04 de dezembro de 2017

Alan Cesar Elias

Deixe seu comentário