Durante minhas apresentações sobre Testes de Software existem
algumas perguntas que são clássicas, sempre fazem no mínimo uma delas.
Por exemplo:

• Mas com testes, demora mais?
• E se demora mais, não fica mais caro?
• E se demora mais e fica mais caro, por que testar?
• Como eu vou mostrar para o meu cliente um relatório de execução de testes? Pirou!?

Pra quase todas eu respondo sim. Sim, simplesmente escrevendo testes
ou trabalhando com TDD/BDD é um pouco mais demorado (medindo
exclusivamente em tempo). Sim, principalmente no começo de um projeto.
Podemos pensar que se demora mais, inicialmente também fica mais caro,
afinal de contas, tempo é dinheiro. Mas depois deste movimento inicial,
e saindo da inércia, o fator de tempo se inverte e o desenvolvimento no
projeto torna-se mais rápido e mais barato. Assim como a manutenção do
projeto.

Após responder sim para esses questionamentos, intencionalmente, eu
inicio a discussão com uma pergunta. Desta vez sou eu quem pergunto ao
congressista: Como você garante a qualidade do seu produto?

Eis que então abro as portas para chegar no ponto principal desta
apresentação sobre Testes de Software: conscientizar as pessoas de que
é necessário testar, pois esta é a forma menos dolorosa para mantermos
não só a qualidade, mas também a vida dos nossos produtos. Mesmo assim
eu sempre tomo cuidado para não vender a idéia de que testes
são a solução pra tudo, muito menos que, pelo simples fato de escrever
testes para todas as funcionalidades do seu sistema, ele não terá bugs
ou problemas, muito pelo contrário.

Mas então por que testar? Pois, até
hoje, testar é a forma mais barata e eficiente que encontramos para
evitar que os problemas cheguem ao cliente/usuário. Eis então aí a
qualidade do seu produto. E quando eu deixo de falar em “testes” para
falar de “qualidade”, consigo a atenção de todos, inclusive de quem
não irá escrever testes, mas quem decidirá se o desenvolvedor terá
espaço para escrever testes ou não, os gestores/líderes.

Geralmente, quando você não escreve testes, qual é a forma utilizada
para garantir que o que será entregue ao cliente está funcionando de
acordo com o que foi especificado (comportamento)? Não sabe responder!?
Bom, então como você faz para garantir que o produto ao menos funciona? Esqueça aqui o modelo de negócios, as telas ao menos abrem? O usuário
não vai receber nenhuma NullPointerException na cara? Também
não sabe responder!? Não tem segurança para responder!? Não fique
triste, infelizmente tem muita gente na mesma situação que a sua.

Na maioria das vezes os projetos de software começam com
funcionalidades e datas de entrega pré-definidas, contratos rígidos,
multas astronômicas, e o pior, fases pré-definidas: requisitos de sistemas, requisitos de software, análise, design, codificação, testes e implantação. Acho que não preciso falar muito do modelo em cascata, o que todos sabemos é que as fases iniciais sempre são feitas pelos “analistas de sistemas”
da empresa, na maior moleza gastando mais da metade do tempo e verba do
projeto sem gerar nada de útil para o desenvolvimento. O que acontece?
Os desenvolvedores simplesmente chutarão os testes (e muitas outras
coisas) pois: não temos tempo agora; depois eu testo; a entrega é daqui a 15 dias; está funcionando sem testes. E, o pior, tentarão justificar a ausência de testes devido a este modelo cultural e organizacional falho.

Então o projeto, de fato, começa. Mas e os releases, como
ficam? Como você garante que o que será entregue ao seu cliente está
funcionando? E que está atendendo a tudo que ele especificou? Estou me repetindo, eu sei, mas é por uma boa causa. Melhor, se sua equipe trabalhou na correção de um bug ou na implementação de uma nova feature,
como você garante que o que foi feito está ok e que todo o restante
continua funcionando como antes? Certamente o seu cliente não espera
que você entregue um relatório de execução da sua suite de testes, mas ele também não espera que você entregue um certificado de garantia ou algo parecido, ele simplesmente confia em você e espera que você faça por merecer.

E você, no começo, faz questão de parar um desenvolvedor ou analista
para testar a funcionalidade que está sendo desenvolvida, ele executa a
aplicação, faz um caso que funciona e outro que não funciona, te
responde ok em cerca de 45 minutos. Passam-se alguns dias e já existem
5 funcionalidades; o mesmo desenvolvedor vai testar e te dá ok em cerca
de 4 horas ou mais. Mais algumas semanas e ele já não testa mais todos
os casos, só os que funcionam e eventualmente pula uma ou outra
funcionalidade pra terminar os testes mais rapidamente. Depois de 3
dias ou mais ele te dá o ok. Imagine depois se o sistema estiver
grande (é mania das empresas, fazer sistemas gigantes), você vai
parar um desenvolvedor por duas semanas ou mais para testar? Ou você
vai manter uma equipe de “testadores”? E como você vai explicar as
regras de negócio de um sistema de controle de transações comerciais
para 5 ou 6 novos funcionários para depois testarem o seu produto? Será
que eles saberão o que fazer e como fazer? Pense em muitos problemas
aqui.

Essa prática é demorada. Se acontecer (e vai acontecer) um problema
seríssimo em produção e você precisar corrigir e entregar rápido, no
mesmo dia, como você vai fazer para testar todo o resto do sistema em
algumas horas? Certamente você vai pensar (e rezar) para que esta alteração
tenha sido pontual e que não afete mais nada no sistema e vai entregar sem
testar. Se as novas solicitações forem de features pequenas,
você não vai querer testar todo o sistema, não vai se preocupar em
fazer um teste de regressão, e vai, novamente, rezar e fazer promessas
acreditando nos poderes sobrenaturais dos seus desenvolvedores. E o
pior é que se alguma vez isso funcionar, esta poderá se tornar uma
prática comum na empresa: alterou; compilou? Então está pronto, pode entregar ao cliente.

Se você precisar economizar ou cortar custos, a primeira equipe a
dançar será a de “testadores” ou, se ela não existir, será o tempo gasto
pelo desenvolvedor que fazia os testes manuais. E com isso você não
cortará somente custos, nesta altura do campeonato este é o seu menor
problema, ou deveria ser a sua menor preocupação, você estará cortando
diretamente a qualidade do seu produto! E sem qualidade a confiança que
o seu cliente tem em você começará a diminuir, a imagem da sua empresa
junto ao cliente começará a perder o brilho e num determinado momento o
cliente se dará conta que você entregou o produto em 4 meses e está há 2
anos tentando deixá-lo totalmente funcional, sem muito sucesso.

Não são somente os testes automatizados que irão garantir a
qualidade do seu produto, você tem outras alternativas e a mais
conhecida são os testes manuais feitos pelo desenvolvedor ou por sua
equipe de testadores, porém esta não é uma alternativa barata e nem
rápida, isso não é sustentável ao longo da vida de um projeto.

Se você e seu cliente não se importam em esperar 15 dias para uma release sair,
tudo bem, não escreva testes; se você não se importa com o alto custo
de manter uma dúzia de pessoas para preencher campos e dar ok, tudo
bem, continue sem testes; se o seu cliente te paga 5 vezes mais para
fazer o produto funcionar do que o ele pagou para ter o produto, tudo
bem também, continue sem testes; ou se os seus desenvolvedores são
especiais e possuem poderes além da nossa compreensão e isto permite
que você não teste, ótimo, você é um sortudo, pode continuar assim. Se
alguma forma sem testes automatizados funciona pra você e você consegue
garantir qualidade assim e ainda consegue ser uma organização
lucrativa, sorte a sua (e coitado do seu cliente). Só que as coisas nem
sempre são assim.

Você deve verificar o seu código, sempre! Você deve testar rápido,
pois precisa entregar rápido. Você deve ter segurança para alterar,
pois sua equipe pode ser nova ou com pessoas que não conhecem o
projeto. Você precisa testar tudo o que foi alterado e todo o resto
para saber se algo não deixou de funcionar com alguma alteração. E você
precisa fazer tudo isso pra ontem, afinal, você está no mesmo planeta
que o resto das pessoas.

Se no início do projeto você tivesse feito o que era necessário, se
tivesse investido em testes e automatizado todos eles, após a entrega
do produto você poderia dedicar os próximos dois anos que iria passar
dando manutenção em código legado (lembre-se que código sem testes já
nasce legado) prospectando novos clientes e projetos. Se aqueles
minutinhos para escrever os testes não tivessem sido cortados, hoje,
quando o produto tiver milhões de linhas de código e centenas de
funcionalidades, após uma alteração qualquer, feita por um estagiário
que chegou ontem e nem conhece o produto, você conseguirá saber em
questão de minutos (ou no máximo horas) o resultado e impacto desta
alteração, com um simples click você saberá se pode entregar a release para o cliente, ou não.

Ao final do projeto, sim, este projeto terá um fim e será concluído
de verdade, aquele tempinho que parecia estar sendo perdido com testes,
pensando que testar uma funcionalidade antes mesmo de ela existir é coisa
de maluco, pensando que o melhor a se fazer é correr e correr e correr
pra entregar logo qualquer coisa ao cliente, tudo isso vai se converter
num ganho inestimável para sua organização, você poderá desenvolver
novas features, trabalhar em outros projetos ou clientes,
movimentar as pessoas entre as equipes, contratar gente nova e
inseri-los rapidamente no ‘ritmo’ de trabalho, e o melhor de tudo, o seu cliente manterá a confiança em você, na sua organização e no seu trabalho.

Então, assim eu termino a discussão: É mais rápido entregar um
produto em 3 meses e levar mais 24 meses ajustando-o para o tornar
funcional ou é mais rápido entregá-lo em 4 meses? Ou entregá-lo em 3
meses com menos funcionalidades? É mais barato arriscar a imagem e
confiabilidade da sua organização entregando algo sem qualidade ou é
mais barato escrever e automatizar testes?