Tecnologia adere testes unitários na versão WEB

Em maio de 1992, a Pepsi começou uma promoção curiosa nas Filipinas


28/10/2014

Em maio de 1992, a Pepsi começou uma promoção curiosa nas Filipinas. Basicamente, se o consumidor achasse uma tampinha com o número 349 impresso no fundo, ele ganharia mais ou menos 40 mil dólares. Infelizmente, devido a um erro de software, 800 mil tampinhas foram impressas com o número 349 em vez de uma só. A Pepsi não pagou $40 mil para cada um que achou as ditas tampinhas, mas deve ter gasto um valor enorme com cada processo aberto pelos "sortudos". Ainda bem que não era a Coca-Cola, se não teriam incluído nos processos que a bebida não desentupiu a pia direito.

Esse foi um exemplo que encontrei quando estava pesquisando algo para escrever esse artigo (falou o jornalista), e fiquei pensando no assunto. Primeiro pensei em como funcionava o processo que decidia que número seria impresso, e deduzi que devia ser algum algoritmo randômico.

Provavelmente pensou-se que o número 349 seria sorteado tão poucas vezes que não valia a pena validar o resultado. Ou talvez foi feito um teste da validade do algoritmo, mas não foi pensado como isso funcionaria em produção. Ou pior ainda, talvez não tenha sido dado muita atenção ao teste do software, e talvez ninguém tenha sido encarregado de verificar os números nas tampinhas depois de impressas. De qualquer forma, estou apenas aventando hipóteses, e é fácil falar de erros de software depois de descobertos.

A verdade é que testar software é tão importante quanto desenvolver software. E não falo daquele teste em que uma pessoa senta em frente ao computador e valida o funcionamento do software, mas do teste que o programador faz. Cada vez é mais importante que um programador saiba escrever não só um bom código, mas um bom teste. A disciplina de testes de software tem se tornado mais completa a cada dia, e existem tantas abordagens e comunidades de teste quanto de codificação. De quebra, software está devorando o mundo, e se antes esse assunto torcia narizes hoje já não é mais assim.

Olhando o próprio quintal

Meu pai costuma dizer que tudo que uma pessoa diz antes do "mas" não vale muita coisa. "Kobe Bryant pode ser tão bom quanto Jordan, mas primeiro precisa se recuperar das lesões." "Pode ter sido um bom filme, mas o livro é muito melhor." "Falar de teste de software é fácil, mas quero ver você aplicar."

Pois é, estou aqui falando de testes, mas nós mesmos passamos anos desenvolvendo um ERP no qual não se podia aplicar esse tipo de teste. Estávamos presos a uma tecnologia descontinuada, e não havia muitas possibilidades de estender as ferramentas. Felizmente, isso está mudando com o crescimento do Systêxtil Web, que é desenvolvido numa plataforma mais moderna e com uma comunidade ativa.

Os testes de aceitação -- aqueles que um usuário valida o funcionamento do sistema -- sempre existiram, mas eles são tão estáveis quanto o Felipe Massa na Fórmula 1. Por isso, recentemente temos investido em uma estrutura que propicie a escrita de testes em tempo de desenvolvimento, e isso exige mudanças de comportamento também. No momento, tudo está em fase incipiente ainda, mas está claro que as novas implementações devem aplicar pelo menos em algum nível a escrita de testes, e já temos uma noção de quais processos estabelecidos que precisem ser cobertos por teste. O desafio de testar um sistema gigantesco, com processos que precisam atender a diferentes necessidades, condicionados a parâmetros, setores e localizações torna tudo mais interessante.

Pra terminar

Por fim, não quero que o que disse acima tenha uma interpretação errada. Implementar testes num software em produção é um grande desafio, e não existe panaceia. Talvez as condições tecnológicas para que apliquemos isso tenham demorado, e com certeza os erros que cometemos no passado têm de servir de aprendizado nessa nova fase. O que importa agora é que enxergamos a necessidade e a oportunidade, e esperamos em breve termos essa prática como natural.

Inscreva-se para receber novidades