Sempre que abordo testes de software nas minhas apresentações e treinamentos, eu uso a metáfora do recall de veículos. Os recalls tem dois principais tipos de custos associados. Primeiro, o financeiro, relativo a advogados, campanha, reposição de peças, que é bem mensurável. E o segundo que é da imagem do fabricante que não é tão mensurável, mas que pode ser tão grande quanto ou maior que o outro.

E o que isso tem a ver com teste de software? A idéia de que quanto mais cedo se descobrirem os defeitos nos produtos melhor. E por “melhor”, eu quero dizer “mais barato”. E qual é a forma de “descobrir defeitos no produto” no caso de software? Isso mesmo, caro leitor: testar.

Só que a atividade de teste é vista pela maior parte das pessoas como algo de pouca importância e/ou muito caro. E veja que eu usei o termo “pessoas” e não engenheiros de software ou desenvolvedores. E antes que alguma sociedade protetora venha me corrigir, não quis dizer que desenvolvedores não são pessoas, eu apenas quis ser mais abrangente.

Os usuários, por exemplo, concordam alegremente em colocar mais rápido um sistema em produção que não foi adequadamente testado. Isso não chega a ser uma surpresa, pois dos usuários não se pode esperar grande coisa mesmo.

Os desenvolvedores também estão sempre muito preocupados com os prazos. Eles parecem não se incomodar em entregar um sistema cheio de defeitos desde que estejam cumprindo o cronograma. Na verdade, o mais comum é o cronograma já ter ido para o brejo e cortar os testes (que são sempre empurrados para o final) acaba sendo juntar a fome com a vontade de comer: entrega-se o projeto mais rápido e ainda evita-se essa coisa chata de testar.

O que mais me chama a atenção é a visão gerencial e executiva sobre isso. Ao invés de enxergar os testes como uma atividade que poupa dinheiro, ao descobrir os defeitos mais rapidamente, os testes são uma atividade supérflua que “não produz nada”. Uma frase que expõe isso muito bem esta linha de pensamento – e que já ouvi algumas vezes – é: o desenvolvedor/programador tem que fazer certo da primeira vez. Como se defeitos em produtos de software fossem plenamente evitáveis sem maiores esforços.

O ser humano fabrica carros a mais ou menos 1 século e eles ainda saem das fábricas com defeitos. E o mesmo vale para telefones, computadores, televisores, produtos alimentícios. Por que seria diferente com software que é um tipo de produto muito mais novo e difícil de ser compreendido?

Para ser justo, é muito dificil provar que o é mais barato testar software, identificar e corrigir os defeitos antes da entrega, do que deixar a “vida me levar” e correr atrás dos problemas quando eles aparecerem. E é aí que nova onda de recalls automotivos pode nos dar uma pista se estamos no caminho certo.

Leio na internet que apenas 1 dos recalls de 1 dos fabricantes pode atingir o impacto econômico de 5 bilhões (com b) de dólares. Apenas nos EUA o prejuízo pode chegar a 2,3 bilhões. Um dos executivos (o CEO se não me engano) desse fabricante já veio a público assumir que reduziu o orçamento da verificação de qualidade dos carros para aumentar o lucro dos acionistas. Coisas do mercado competitivo. Não sou contador, nem executivo de empresa e nem fiz MBA, mas me parece que um custo de 5 bilhões (com b!!!) não ajuda a aumentar o lucro de empresa nenhuma.

Quanto será que custa um programa de verificação de qualidade para essa empresa?

Agora notem a sutileza: e quanto vale evitar que os carros saiam com defeitos tão severos das fábricas?

Fazer correlação entre duas indústrias, como a indústria de software e a indústria automobilistica, é sempre um exercício arriscado. Existem muitas especificidades. Mas, acho que um bom programa de testes de software deve ser, guardadas as devidas proporções, tão importante para qualquer organização que desenvolve software quanto evitar os recalls deve ser para as montadoras.

Em outras palavras, testar software ajuda a reduzir custos e riscos; ainda que na hora do teste isso não apareça nas planilhas.

Tags:  teste recall