Testes automatizados? Por onde eu começo?

O texto de hoje tem a intenção de explorar uma pergunta que vez ou outra escutamos de algum cliente. É comum ouvir frases do tipo: “Já enxerguei a importância de ter testes automatizados! Os testes 100% manuais estão sacrificando nosso tempo e a qualidade do release! Mas por onde a gente começa? Que tipo de testes usamos para começar a automatizar?”

Como preâmbulo, que bom que a necessidade de automatizar os testes já está clara! Não é nada razoável mantermos  pessoas em nossos projetos com o propósito único de rodar testes de forma manual.  Esse trabalho pode ser automatizado com um grau de confiabilidade bem alto,  liberando as pessoas (por exemplo, as pessoas da área de testes) para funções mais nobres e produtivas, como elaborar e executar testes exploratórios em casos ainda inexplorados ou não pensados:

  • impedir que alguns campos aceitem datas como 29/fev em anos que não são bissextos (esse erro aqui é digno dos bons testadores! Não é qualquer um que pensa com esse tipo de maldade!)
  • informações importantes que deveriam estar na tela mas não estão
  • erros de português em labels, mensagens etc.
  •  “corner-cases
  • etc

É fato que existem vários tipos de testes automatizados que podem ser feitos: unitários, integração, funcionais, aceitação. Por onde começar a testar no seu sistema ?   testesAceitacao Sem dúvida, por onde houver maior ROI (Return on Investiment) e, normalmente, nos casos de sistemas que já possuem algum tempo de desenvolvimento, esse ROI é maior se começarmos atacando pelos testes de aceitação. Por quê? Os testes de aceitação são por natureza testes caixa-preta, e são os testes que mais facilmente expressam o que o cliente gostaria de fazer ou ter no seu software. Desta forma, tendem a ser altamente alinhados com as regras de negócio (expressas por exemplo através das Histórias de Usuário).

Como insumo para escrever os testes de aceitação, podemos (ou devemos!) usar os critérios de aceitação descrito pelos Product Owners nas Histórias de usuário. Estando estes testes implementados, rodando, e passando com sucesso,  obteremos uma boa cobertura e garantia de que pelo menos as funcionalidades mais importantes estão sendo de fato cobertas pelos nossos testes. O mais importante, todo esse feedback acontece em poucos minutos e sem necessidade de intervenção humana!

Esse tipo de teste pode/deve rodar em um robô de Integração Contínua (Jenkins, TravisCI, Hudson, CruiseControl etc), que fará o trabalho de rodar os testes por você, de acordo com alguma estratégia pre-definida (todo dia , a cada modificação feita no código-fonte etc. ).

E como é a anatomia de um teste de aceitação?

Basicamente, este tipo de teste pode ou não usar uma pegada Comportamental (BDD),  devem manipular a interface como se fosse um usuário (usando ferramentas como o Selenium WebDriver) e garantir o estado encontrado no banco de dados antes mesmo do teste rodar (para evitar testes vaga-lume, que as vezes passam e as vezes não passam).

Hoje em dia conseguimos implementar este tipo de teste em praticamente todas as linguagens ditas “comerciais” (Java, Python, C#, Delphi , Ruby etc.). Claro que, por ser um teste caixa-preta, você saberá que há um problema mas não saberá em que camada exatamente do seu sistema o problema reside. Testes desse tipo sinalizam um erro (o que é ótimo), mas deixarão a cargo dos desenvolvedores a tarefa de buscar o ponto exato do problema (o que pode ser chato, gerando necessidade de debugs enormes). Costumo fazer a analogia de que testes de aceitação são ótimos “zoom out” do sistema, enquanto que testes unitários (caixa-branca) são ótimos em zoom-in do problema. Em resumo: legado Uma última dica dica é que, salvo raras exceções, não vale a pena começar pelos testes unitários. É comum encontrarmos sistemas legados altamente acoplados e desenvolvidos sem a preocupação de serem “testáveis” unitariamente. Testar unitariamente significa isolar todas as outras classes/componentes para que possamos testar unitariamente um determinado pedaço de nosso código. Como fazer isso se o software muitas vezes está parecendo um castelo de cartas? Definitivamente não é a melhor estratégia.

Espero que tenham curtido o post e gostaríamos de ter feedback de vocês, leitores, para os próximos assuntos sobre testes que devemos abordar! Mande sua sugestão para nosso email ou page no facebook!

Treinamentos Relacionados

Leia mais

Click here to read this post in english.

Sobre o Autor:

3 Comments

  1. […] Testes automatizados. Por onde eu começo? […]

  2. […] Testes automatizados? Por onde eu começo? […]

  3. […] Você concorda com os pontos acima? Quer acrescentar algo? Vamos conversar mais sobre este assunto tão polêmico mas que é essencial nesta fase de transformação digital que estamos vivendo. Não sabe por onde começar com testes automatizados? Então dá uma lida em um outro post que fizemos: Por onde eu começo com testes automatizados. […]

Os comentários estão encerrados.