Teste de software
Se a “falta de foco” é decorrente do “Just do it” (apenas faça), então a repetitividade é o resultado de “apenas fazer mais”. Sucesso após sucesso, build após build, sprint após sprint, versão após versão, nós testamos nosso produto. Desenvolvedores fazem revisões, escrevem testes de unidade e realizam análise estática. Mas nós testadores temos pouco conhecimento dessas atividades. Desenvolvedores testam, nós retestamos.
Não podemos assumir nada sobre o que eles fizeram, então retestamos tudo. A medida que nosso software cresce, novas funcionalidades são desenvolvidas e os bugs são corrigidos, e nós continuamos nossos testes. Não demora muito para que nossos novos testes fiquem velhos e inevitavelmente tornem-se obsoletos.
Este é o paradoxo do pesticida, definido por Boris Beizer. Pesticida mata os insetos, mas se você aplicar o mesmo pesticida muitas vezes, eventualmente os que sobrarem serão imunes. Aplicar e reaplicar é um processo adequado para lavar cabelo, não para teste de software. A última coisa que precisamos é uma versão repleta de “superdefeitos”, imunes ao nosso “testicida”. Pior ainda, esses supostos testes “bem sucedidos” irão gerar uma falsa sensação de segurança e transformar nossas métricas de completude dos testes em perigosas mentiras. Quando não achamos bugs, não é porquê eles não existem, mas porquê a repetitividade está criando o paradoxo do pesticida.
Fazendeiros ajustam seus pesticidas de tempos em tempos, tanto para evitar que as pragas tornem-se resistentes, quanto para atacar pragas que eles esperam encontrar. Eles o fazem porque entendem a história do pesticida que usam e sabem que não serão bem sucedidos apenas com uso de força bruta e o mesmo velho veneno. Testadores devem prestar atenção aos resultados dos testes e ficar atentos à automação que não agrega valor. É necessário inserir um pouco de variação, saudável, nos testes automatizados.
Mude a ordem