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