E a qualidade, como você garante?

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 que 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” eu 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 da 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 da o ok. Imagine depois que o sistema estiver grande (é mania das empresas querer 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) que esta alteração foi pontual e que não afetará 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á a 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 2 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 dela 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?


12 comentários sobre “E a qualidade, como você garante?

  1. Pingback: Jeveaux
  2. Eu não concordo com a afirmação que fazer testes demore mais, que se a abordagem for TDD desde o inicio o desenvolvimento é até mais rápido principalmente quando vai para integração.
    eu sei que você sabe disso e tenta rebater os argumentos contrários, mas temos que mostrar que com testes além de seguro o dev é muito mais rápido!

  3. Muito bom Jeveaux!

    O mais dificil é fazer com que os desenvolvedores, gestores e toda a equipe entendam que testes automatizados (ou não) não são perda ou gasto de tempo, mas sim um investimento.

    Enfim, muito bacana o post!
    Abraços.

  4. Pingback: Jeveaux
  5. Pingback: Alberto Leal
  6. Pingback: Cairo Noleto
  7. Concordo com tudo, só não concordo com o inicio quando respondendo às perguntas dos congressistas você informa que o inicio do projeto é um pouco mais demorado trabalhar com BDD e TDD. Nem sempre. Muitas vezes fazer o teste antes torna o trabalho mais rápido, pois não é preciso executar testes manuais repetidamente sempre que se está ajustando um algoritimo, e torna a identificação do ponto errado mais fácil. Isso tudo economiza tempo. Acho que demora mais quando a pessoa ainda não está acostumada a escrever testes.

  8. Parabéns Jeveaux, acho que você ressaltou a importância de TDD/BDD de maneira ponderada. Embora acho testes imprescindível, temo quando vejo pessoas colocando as técnicas envolvidas no assunto como messias de todos.

    Quanto a gastar mais tempo ou não, isso varia. Quando envolve a mudança de paradigma para os desenvolvedores, já vi experiências que realmente o tempo no inicio aumentou. Mas conforme isso realmente entra no dia-a-dia de todos da empresa esse tempo é sensivelmente diminuido, quando não, nem percebido.

  9. Muito bom. Concordo com você, um dos maiores benefícios dos testes está na segurança que eles proporcionam para que possamos realizar alterações. Pela minha experiência com testes, na maioria das vezes, realmente, desenvolver com testes é um pouco mais demorado, porém, se levarmos em conta o tempo que não gastamos com debug e testes manuais, no final das contas dá pra levar vantagem, e muita.

    Abraço

  10. Valeu pelo feedback galera.

    A todos que não concordaram sobre o início do post sobre o ‘aumento de tempo’ quando se faz TDD/BDD, eu também concordo com vocês, pra quem já está acostumado e sabe o que está fazendo é mais rápido mesmo. Porém acho que não deixei muito claro no texto, eu digo que demora mais pois as pessoas que perguntam (sempre), são pessoas que não tem esta cultura, logo, pra elas vai demorar um pouco no início mesmo, só que ‘depois de sair da inércia’ aí as coisas mudam de figura.

  11. Fantástico post! Sabe o que é pior, nas famosas empresas 3 três letrinhas, o “Analista de Testes” nunca ouviu falar de uma simples ferramenta de teste funcional como o Selenium IDE. É legal ver os caras repetir a mesma coisa verificação manual depois da correção de bugs.

    Você gasta mais tempo para fazer a primeira vez, claro que gasta, é evidente! Mas se o teste tiver que ser refeito, o gasto com testes novamente é mínimo.

    No último projeto que participei, tinha uma função javascript e uma funcionalidade que eram usadas em todas as histórias. Ao chegar na penúltima, descobrimos uma falha em ambas, como usamos Selenium para testes funcionais, em questão de poucos minutos, aqueles testes detalhados foram todos refeitos. Fazendo uma analogia, as pessoas querem ter uma vida saudável mas não acordam 2 horas por dia mais cedo para uma caminhada ou corrida. Isto também acontecem com desenvolvimento de de software, as vezes falta atitude.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios são marcados com *