As pragas do teste de software — parte 1

Cada área de atuação tem questões e problemas inerentes às atividades que exercem. Na área de testes de software, esta realidade não é diferente. Diariamente nos deparamos com situações trabalhosas e muitas vezes desgastantes, que constantemente nos desafiam.

No último final de semana estava revisando uma série de anotações que havia feito em meados de 2009, quando já estava me dedicando exclusivamente a esta empresa maravilhosa que é a Sofist. Tive a grande alegria de encontrar um material de James Whittaker, que naquela época era diretor de testes no Google. Sou muito fã dessa pessoa, já li inúmeros livros, e em 2009 ele escreveu uma série de artigos sobre as pragas existentes no mundo de testes de software, exemplificando de maneira bem didática os maiores problemas e desafios que os testadores têm em seu dia-a-dia.

Naquela época, tive a oportunidade de falar diretamente com ele e ter o privilégio de poder traduzir e adaptar o material, afinal achamos relevante compartilhar com os profissionais da área de tecnologia assuntos pertinentes e que trazem boas reflexões sobre nosso dia-a-dia de trabalho.

Alguns anos depois, relendo o material, é incrível como conteúdo ainda tem tudo a ver com o cenário que observo hoje nas empresas. Por isso resolvi trazer uma série com dois textos abordando as pragas apontadas por Whittaker. Já eliminei muitas das pragas dentro da Sofist (inclusive variantes delas), e garanto que exterminá-las fará com que seu time tenha cada vez mais sucesso!

A praga da falta de foco

Sabedoria. Muito mais que uma palavra interessante, este termo invoca em nossa mente a imagem de um feiticeiro e seu milenar livro de magias ou ainda a imagem de um poderoso mago com seu conhecimento arcano arduamente obtido.

É exatamente esta sabedoria que nos falta sobre teste de software. Sabedoria sobre testes? Sério? Onde está? Quem está distribuindo? Posso experimentar?

A indústria de teste de software está infectada com a praga da falta de foco. Nos falta sabedoria, nos falta um corpo de conhecimento que seja passado do mago para o aprendiz e escrito nos livros de magia para os intrépidos e esforçados estudarem. Nossos aprendizes estão sem seus mestres e todos nós precisamos reinventar a roda. Não só, reinventamos na privacidade de nossos escritórios, enquanto outros testadores ao redor do mundo também a reinventam em seus próprios escritórios.

Homem trabalhando sem foco

Sugiro que paremos com essa estupidez. O teste de software está muito à deriva. Testamos apenas porque devemos ou porque nosso gerente mandou. Automatizamos porque conseguimos ou porque sabemos como, não porque isso faz parte de alguma estratégia definida e certamente não porque a “Sabedoria” nos diz para fazê-lo. Existe um plano ou conhecimento que guia nossos testes ou estamos apenas pressionando teclas com esperança de que algum defeito apareça? Onde estão os livros de magia dos testes? Certamente o conhecimento obtido por nossos antepassados testadores pode ser encontrado nesta era de informação, não?

Quando caçadores conseguem uma caça, eles registram o terreno e as circunstâncias. Eles passam essa informação para seus sucessores. Eventualmente, eles entendem os hábitos de suas presas e o conhecimento coletivo de muitos caçadores faz com que o trabalho dos futuros caçadores seja muito mais fácil. Quando você encontrar este terreno, pode-se esperar que o jogo aconteça dessa forma. Podemos dizer o mesmo sobre a atividade de teste de software?

Quão bem aprendemos uns com os outros? Nossos “momentos eureka!” são registrados para que futuros testadores não sofram da mesma falta de foco que sofremos? Podemos dizer que quando você se depara com uma funcionalidade, você já sabe o melhor jeito de testá-la?

A praga da falta de foco está disseminada. A necessidade de sabedoria sobre testes é evidente. A Nike nos diz “Just do it” (apenas faça), mas o que se aplica aos exercícios físicos não é um bom conselho para os testes de software. Da próxima vez que você perceber que está “apenas testando”, pare por um momento e se pergunte “Qual meu objetivo?” e “Existe um propósito para este teste?”. Se as respostas não vierem imediatamente à sua mente, você está sem foco, dependendo da sorte e de esforço bruto para encontrar sua mina de ouro.

Se as respostas não vierem imediatamente à sua mente, você está sem foco, dependendo da sorte e de esforço bruto para encontrar sua mina de ouro.

Sorte não tem lugar na feitiçaria, na casa ou no teste de software. Sorte é um bônus, mas não pode ser nosso “plano A”. Fique atento à praga da falta de foco. Documente seus sucessos, examine cuidadosamente suas falhas e assegure-se que o que você aprendeu seja passado para seus colegas.

Seja o mestre deles. Construa seus volumes de conhecimento sobre testes e divida-os com seu time. Com tempo, você irá banir a praga da falta de foco.

A praga da repetitividade

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.

Abrindo um parêntesis, os desenvolvedores de software de fato estão fazendo isso? Em centenas de empresas que já visitei nos últimos 9 anos, consigo contar na mão aquelas em que os desenvolvedores criavam seus testes unitários. Análise estática?!? Já oferecemos solução com foco em análise estática aqui no Brasil, e sempre esbarramos em argumentos de que era muito caro, afinal melhor correr o risco de perder um contrato de alguns milhões do que investir 70 mil dólares anualmente para ter certeza de que o produto seria entregue com maior qualidade. Assustador, não?!? Mas nada diferente do que ainda vejo em 2018 (fechando o parêntesis).

Sprint repetitivo

Enfim, nós testadores temos pouco conhecimento dessas atividades mais técnicas que acontecem. 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 super-defeitos, 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 porque a repetitividade está criando o paradoxo do pesticida.

Pesticida na agricultura

Eu particularmente já vivenciei muitas, mas muitas situações mesmo em que escutei que o time não estava encontrando mais bugs no produto. Em todos os casos, sempre perguntei se a estratégia para encontrar os bugs já havia sido mudada; em 90% dos casos, a resposta era não. O Paradoxo do Pesticida é fantástico, pois reforça que os testadores precisam ser criativos o suficiente para criarem novas fórmulas para encontrarem bugs, seja mudando técnicas, seja combinando técnicas diferentes.

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. Inclusive é necessário inserir um pouco de variação, saudável, nos testes automatizados, além de prestar atenção à automação que não gera valor. Mude a ordem dos testes, mude a fonte de dados, encontre novos ambientes para executar, altere os valores de entrada! Enfim, faça algo que pegue os bugs desprevenidos!

A praga da amnésia

A memória é uma das primeiras coisas que se perde à medida que se envelhece. Porém, comparada às demais engenharias, a engenharia de software dificilmente pode ser chamada de velha. De fato, comparado à engenharia civil, elétrica e muitas outras, somos muito novos. Por isso, não podemos utilizar idade como desculpa para nossa amnésia.

Existem dois tipos de amnésia que assolam os testadores de software. Temos a amnésia da equipe, que faz com que esqueçamos nossos projetos, bugs, testes e falhas que nos antecederam. Está na hora de desenvolvermos uma memória coletiva que nos ajude a parar de repetir os mesmos erros. Cada novo projeto não é um novo começo, mas apenas um novo objetivo para uma equipe mais experiente. A nave espacial Enterprise mantém um diário de bordo, que documenta as aventuras da tripulação e que pode ser consultado atrás de detalhes que possam auxiliar a tripulação a sair de alguma dificuldade atual. Não estou defendendo o uso de um diário pelas equipes de testes, mas espero que a equipe possua algum mecanismo para retenção do conhecimento. Quanto maior a memória da equipe da Enterprise, melhor sua execução.

Rápido!!! Diga qual o último grande fracasso do produto pelo qual sua equipe é responsável? Sua equipe tem uma memória coletiva dos bugs mais comuns? Vocês dividem os bons testes? Se alguém escreve um teste para uma certa funcionalidade, todos são informados para que possam gastar seu tempo testando outra parte do sistema? Os problemas que quebram seus testes automatizados são documentados para que a trabalhosa análise para corrigi-los não precise ser repetida? Os membros da equipe sabem o que cada um está fazendo, de modo que seus testes se sobreponham o mínimo possível? Isso tudo é alcançado através de quadros e comunicação constante, ou os únicos pontos de sincronização são as reuniões (que param o trabalho e desperdiçam tempo)? Responda sinceramente. O primeiro passo para recuperação é admitir que você possui um problema.

Homem apoiando a mão na cabeça tentando lembrar algo que esqueceu

 

O segundo tipo de problema de memória é a amnésia industrial. Quando mencionei Boris Beizer e o paradoxo do pesticida, quantos de vocês tiveram que se informar sobre o assunto? E os que sabiam do que se tratava, como andam seus conhecimentos sobre REACT? Seja honesto… Existem aqueles que têm tanto uma perspectiva histórica quanto conhecimentos modernos, mas esses são raros demais. Nosso conhecimento, aparentemente, não é coletivo, é situacional. Aqueles que se lembram das descobertas de Beizer trabalhavam em um mundo onde não existia REACT e aqueles que falam “webinês” fluente perderam muito do pensamento e conhecimento de base. Lembrar-se apenas do que está à nossa frente não é memória de fato.

Amnésia da indústria é um problema real. Pense dessa forma: aquele problema de teste de software, à sua frente, já foi resolvido antes. Você está testando um sistema operacional? Alguém já testou muitos deles. Web application? Sim, já foi testado. REACT? Cliente-servidor? Serviço na nuvem? Sim, sim e sim, já foram testados. As chances são que o que você está testando já foi testado antes. Existem alguns problemas novos na área de teste de software, mas provavelmente o que está à sua frente não é um deles. Infelizmente, a memória da indústria é tão ruim, caso contrário seria fácil buscar ajuda.

Agora vamos refletir sobre o seu projeto: Como você (ou seu time) irá testar o próximo produto que será lançado por sua empresa? Quanto conhecimento coletivo vocês desenvolveram em cima das tecnologias já utilizadas? Quanto do que aprenderam testando as versões anteriores do produto irão te ajudar? Quanto será reaproveitável? Com que facilidade as equipes de testes desses projetos se adaptarão a esse novo desafio? Com certeza muitos dos problemas serão iguais aos que vocês já enfrentaram anteriormente.

Afinal, será que iremos nos lembrar?

Provocativo, não? Já parou para pensar nas questões da falta de foco, repetitividade e esquecimento dentro de sua empresa? Se você é um gestor, já olhou para seu time com esta ótica? Você, QA, se enxergou em algumas destas situações? Muitas e muitas perguntas, que chegam até a incomodar. Mas isso é muito mais comum que você imagina!

Falarei das pragas restantes no próximo texto, daqui a duas semanas. Se tiver dúvidas sobre alguma praga ou quiser conversar melhor sobre como combater estes problemas em sua equipe, me mande um e-mail em bruno.abreu@sofist.com.br ou ligue em (19) 3291-5321 e vamos conversar melhor sobre o assunto!

  • Urânia dos Santos Reis

    Bruno ótimo texto, sua argumentação foi perfeita!!! Abraços.

  • Tiago2014

    Bruno parabéns pelo ótimo texto produzido. Essas pragas também se aplicam em outras áreas, e até pessoalmente!
    Aguardando segunda parte.

  • reborn

    e quando tem que testar um monólito em delphi 7?
    Não tem nem documentação atualizada,muito memoria dos testes realizados no passado.