Testes automatizados: por onde eu começo?

Este post não tem tags.

Compartilhe:

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.

Testes automatizados: aceitação

É 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?  testes automatizados: aceitaçãoSem 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-pretae 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 é 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 nos comentários!

Treinamentos Relacionados

Leia mais sobre Testes Automatizados

Escute agora o episódio sobre Testes Automatizados do podcast Love The Problem!

Sobre o autor(a)

Cofundador e Trainer na K21

Carlos Felippe Cardoso é cofundador da K21 e tem experiência em métodos ágeis desde 2004. Palestrante nos maiores eventos de agilidade do Brasil e da Europa, é instrutor do treinamento de CSD (Certified Scrum Developer), pela Scrum Alliance, e também instrutor oficial de Kanban (AKT – Accredited Kanban Trainer), pela Kanban University. Como Executivo, possui vasta experiência em Transformação Digital e Liderança, atuando especialmente no C-Level de empresas.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

É uma pergunta comum em diversos times ágeis: Temos capacidade para atender a demanda? A resposta é não. Como diz Rodrigo de Toledo: “No trabalho do conhecimento, a demanda sempre irá superar a nossa capacidade de atendê-la.”. O desafio é…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…