Desenvolver software utilizando automação de testes é uma das bases das metodologias ágeis, pois mostra-se como a única maneira de garantia de entrega contínua e sustentável.

Automação de testes é uma forma de aumentar a produtividade, diminuir custos e conseguir níveis de entrega em outra ordem de grandeza se comparado à processos manuais de testes.

Então por que a maioria das empresas de desenvolvimento ainda relutam tanto na aplicação desta técnica?

Quais são as dificuldades, mitos e crenças que impedem o sucesso deste investimento?

Em nosso time, descobrimos o poder desta técnica a quase 20 anos.

Não tínhamos muitas referências e nem ferramentas para nos auxiliar, mas sabíamos que para conseguirmos garantir a robustez do que estávamos entregando cada vez mais os testes manuais se mostravam ineficientes, demorados e muito custosos.

Começamos assim desenvolvendo frameworks para o suporte desta técnica e criando processos de forma a fomentar uma cultura que levava em conta a automação de testes em todo o ciclo de produção do software.

Já tínhamos um grande legado desenvolvido sem testes, mas apostamos em um modelo de introdução de mudanças parciais de forma contínua pautada pela própria necessidade: cada nova feature só era entregue com teste automatizado e qualquer alteração em código legado também envolvia o desenvolvimento de testes para este código descoberto.

Para bugs encontrados, o processo de correção exigia que primeiramente se faria um script de replicação deste para somente depois atuar na correção do mesmo.

Por vezes tivemos que ter investimentos maiores de arquitetura, mas os ganhos foram muitíssimos recompensadores.

Antes da automação de testes

Nossa empresa foi fundada em 1995 a partir de uma reunião de estudantes ‘nerds’ que gostavam de programar seus próprios jogos de computador.

Apaixonados por desenvolvimento de software, desde o princípio tinham o intuito de primar pela qualidade e sustentabilidade das suas entregas e por isso escolheram a linguagem Smalltalk dado o paradigma de Orientação a Objetos pura que tal tecnologia oferecia.

De fato, acredito que esta seja uma das razões pelo pioneirismo na automação de testes.

Ao mesmo tempo que o ambiente propiciava alta flexibilidade (não tipado, IDE aberta, O.O. puro, etc.), a comunidade, especialmente nacional, não era muito grande, o que gerava a necessidade de criação própria das ferramentas e frameworks necessários para o ambiente de desenvolvimento.

Começamos atendendo uma empresa de Telecom na área de TVs por assinatura e em menos de 1 ano já tínhamos um grande sistema em produção, responsável pelo core bussiness do cliente. Com camada de persistência própria e vários conceitos que viriam a se tornar Design Paterns somente muitos anos depois.

Nossa história com automação de testes

Apesar da vanguarda na aplicação de modernos padrões de desenvolvimento, não estávamos imunes aos bugs de software.

Isso é inerente a qualquer processo de desenvolvimento quando este alcança determinado estágio de escala, complexidade e integração paralela de código pela equipe.

Assim, como em outras empresas, iniciamos com uma equipe de testes a qual era responsável por validar novos comportamentos bem como reexecutar scripts para a garantia que o funcionamento antigo não fosse prejudicado pelo novo desenvolvimento.

Contudo, por mais senioridade que a equipe de testes tivesse, a cada novo desenvolvimento esta já não conseguia mais dar conta dos scripts a serem rodados e, assim, nossa taxa de defeitos ia aumentando a cada nova release gerada.

Após sucessivas situações de riscos do negócio do cliente, estabelecemos que não era mais humanamente possível acompanhar com testes o crescimento esperado das nossas entregas.

Queríamos colocar novas versões a cada mês e até tínhamos uma capacidade de implementação bastante grande, contudo de nada adiantava se ficávamos reféns do risco ou do tempo para testes regressivos.

Realizando um simples cálculo de custos, conseguimos enxergar que na realidade estávamos desperdiçando tempo em tarefas repetitivas e que o mais sensato era automatizar estas tarefas através da automação do processo de testes.

Criamos então, ente 1997 e 1998 nossa primeira versão de um framework capaz de registrar e executar um conjunto de scripts de testes que passamos a automatizar a partir de então.

automação de testes

Framework de testes: automação de testes

Este framework já possuía bastante funcionalidades interessantes, algumas destas ainda não visíveis em frameworks atuais de suporte a automação de testes:

  • Hierarquia de scripts,
  • Gravação dos resultados dos testes
  • Comparação entre execution turns (gerando análise de módulos mais sensíveis a erros)
  • Execuções parciais da árvore
  • Navegação facilitada do teste para o código onde ocorreu a quebra
  • Utilização de scripts de instalação que garantia rapidamente a montagem de novos ambientes a partir do zero

Automação de Testes e Cultura Extrema

Hoje utilizamos outras linguagens de desenvolvimento, mas ainda com uma cultura extrema em orientação a testes solidificada pela mesma estrutura definida no passado.

Passados quase 20 anos desde a criação deste framework, temos ele em uso com muitas evoluções e de forma acoplada às principais ferramentas de mercado.

E aqueles primeiros cenários, criados a quase duas décadas, continuam rodando a cada build gerado em um processo de continuous delivery.

Durante esta nossa história, nos deparamos com muitos desafios e obstáculos parecendo insolúveis, mas com persistência, sem medo de tentar e compromissado com a qualidade, chegamos a um patamar em que poucas empresas mundiais se encontram na maturidade do processo de desenvolvimento de software.

Um exemplo deste sucesso se mostra em nossos números: em nosso produto principal, temos um build estável a cada commit o qual dispara a execução de mais de 40.000 scripts de testes funcionais.

E, tudo isso, se repetindo dezenas de vezes ao longo de um único dia.

 

O que aprendemos com a automação de testes

 

Ao analisar todo a nossa história de testes automatizados, fica até difícil separarmos nossas lições aprendidas.

Para nós, desenvolver com automação de testes já não é mais uma questão de opção.

É nosso jeito natural de desenvolver software.

Para fins didáticos, contudo, creio que podemos listar aqui quais foram os maiores benefícios percebidos ao longo desta nossa trajetória:

  • Confiabilidade na entrada de um sistema em produção: Testes automatizados mudaram a forma com que passamos a encarar um ‘go-live’. De ‘momento extremamente crítico e estressante’ para apenas uma fase normal no nosso processo de entrega;
  • Redução de gastos: Testes automatizados são mais baratos que testes manuais;
  • Redução de bugs: Diminuímos em mais de 80% a incidência de bugs. Bugs críticos passaram a ser extremamente raros. Bugs reincidentes simplesmente desapareceram;
  • Prevenção de erros por terceiros: Em cenários com comunicação com outros sistemas, prevenimos a incidência de falhas causadas pelos demais, bem como erros de interface de nosso próprio sistema. Geramos confiabilidade aos outros de forma a facilitar bastante a análise de integrações;
  • Diminuição de falhas de análise: Ao pensar em testes automatizados desde a concepção do software, também diminuímos a incidência de erros de análise pois obrigou um pensamento mais estruturado e concreto na expectativa dos resultados;
  • Transparência na atuação dos problemas: Testes automatizados deixam os cenários mais claros e diretos. Bons testes são capazes de validar cada aspecto de um desenvolvimento e permitem melhorias e correções pontuais;
  • Redução do tempo de desenvolvimento: Por mais contraditório que seja, desenvolver com testes automatizados é muito mais rápido que sem eles. Basta a mudança de cultura e uso cotidiano pela equipe;
  • Refactoring: Débito técnico é algo que pode ser atacado sem receios. Percebemos isso quando passamos a utilizar os testes automatizados em larga escala: as pessoas simplesmente não tinham mais medo de melhorar o seu código;
  • Permite validação de alternativas: Com testes automatizados a análise de ‘go/no go’ é muito mais assertiva. Rapidamente conseguimos evidenciar impactos no sistema e validar se o investimento é vantajoso ou não em termos técnicos,
  • Treinamento e documentação: A partir da cobertura do sistema por testes automatizados percebemos que na realidade os scripts criados passaram também a serem usados como forma de explicarmos nosso sistema para novos integrantes da equipe e mesmo novos clientes. É uma documentação viva e sempre atualizada com as funcionalidades que temos em vigência no nosso software.

Para nós, automatizar testes é ainda o único caminho para a manutenção e escala de um sistema e, de fato, no atual cenário de engenharia de software, entregar um produto sem testes automatizados deveria ser considerado uma quebra de ética profissional:

“Sem desculpas! É nossa responsabilidade básica garantirmos a sustentabilidade do que estamos entregando. ”

Marcelo Walter
Agile Coach Objective
mlwalter@objective.com.br