A automação de testes tem um papel importantíssimo na qualidade do software a ser gerado. Os testes automatizados permitem que um sistema seja estressado, apontando falhas na implementação e mesmo na definição das regras de negócio, bugs e outros tipos de falhas. A operação manual dos testes tende a não ser tão efetiva quanto os testes automatizados, evitando que um operador deixe de realizar alguma etapa ou não considere todos os cenários. Ao se definirem testes automatizados, o tempo é investido na sua elaboração e preparação, enquanto sua execução ocorrerá de forma autônoma. Entretanto, existem alguns importantes aspectos na utilização de testes automatizados que podem ser melhorados, como em muitas empresas que ao iniciarem nas atividades de testes automatizados focam em testes realizados diretamente na interface com o usuário (UI – User Interface).

O que ocorre é que, ao focarmos nos testes de UI, acabamos por penetrar pouco nas camadas inferiores do software – onde justamente os maiores esforços de testes deveriam estar concentrados. A abordagem preconizada por Mike Cohn, em seu artigo The Forgotten Layer of the Test Automation Pyramid, diz que para uma estratégia de testes se tornar mais eficiente, ela deve estar dividida em três níveis: os testes de unidade (unit); os testes de serviço (service), também chamados de testes de integração; e os testes de UI. Uma boa estratégia de testes automatizados deve contemplar uma quantidade muito grande de testes de unidade, seguidos por uma quantidade um pouco menor de testes de serviço, e por fim uma pequena quantidade de testes de UI, formando uma pirâmide.

Os testes de unidade permitem avaliar as menores unidades de código desenvolvidos, normalmente um módulo ou classe, ou algumas vezes até mesmo um método mais complexo. Já os testes de serviço testam o software na camada diretamente inferior à UI quando as diversas unidades foram integradas em serviços. Os testes de UI, por sua vez, focam no sistema conforme percebido e operado pelo usuário, através de sua interface.

Quando investimos em uma grande quantidade de testes de UI, além de termos testes mais demorados em sua execução, dispendemos muito tempo em sua elaboração, com pouca rastreabilidade da verdadeira origem do problema. Isso resulta em tempos de depuração mais longos, com custos consequentemente mais altos, e que nem sempre são tão efetivos quanto se esperaria. No final das contas, o que temos é uma pirâmide inversa, ou um “cone de sorvete”, com pouca penetração na camada de unidade para uma grande quantidade de testes.

Unit testing frameworks

Considere adotar um “unit testing framework” ou um framework para testes de unidade. Esses frameworks, normalmente específicos para uma linguagem, são normalmente produtos de terceiros, e fazem com que o processo de testes de unidade se torne mais simples. Embora seja possível desenvolver testes de unidade sem um framework, através de um código cliente que exercite as diversas possibilidades de uso do código, a adoção de um framework normalmente confere maior agilidade aos testes.

Padrões

A adoção de padrões (patterns) traz ganhos de qualidade aos testes. É o caso, por exemplo, do PageObjects, que representa áreas de sua UI como uma série de objetos. Isso permite implementar o que Martin Fowler descreve como “Subcutaneous Tests”.

Ferramentas

Procure utilizar ferramentas que tornem seus testes mais produtivos. É o caso de headless browsers, que são browsers sem uma interface gráfica, que conferem uma maior velocidade aos seus testes.

Desenvolvimento ágil

Utilizar técnicas de desenvolvimento de software ágil, além de conferir uma maior capacidade de entrega rápida e uma melhor resposta a mudanças, permite que os testes sejam melhor planejados e conduzidos. É o caso de técnicas como Test-driven Development (TDD) ou Behavior-driven Development (BDD), que podem ser traduzidos como desenvolvimento guiado por testes e desenvolvimento guiado por comportamento, respectivamente. Existem frameworks que auxiliam na adoção dessas técnicas.

Paralelismo nos testes

Um dos principais ganhos em testes automatizados é a possibilidade de executá-los em paralelo, com ganhos no tempo de execução. Isso confere ainda mais agilidade ao processo de desenvolvimento como um todo.

Testes de baixo nível

Por fim, cabe ressaltar que o foco deve realmente estar nos testes de baixo nível. Os testes de nível mais alto devem funcionar somente como uma “segunda linha de defesa”. Um erro detectado em um teste de UI não só indica que existe algum bug no código de baixo nível, mas também que algum teste de unidade que deveria ter sido feito, não o foi. Portanto, ao corrigir problemas apontados por testes de ponta-a-ponta que falharam, também deve-se tentar determinar qual teste de unidade deve ser adicionado.

Como é a estratégia de testes automatizados de software na sua empresa? Conte para a gente nos comentários!