Pirâmide de testes — uma boa estratégia para automação de testes na prática
Como definir uma boa estratégia para automação de testes?
Por Rogerio Oliveira e Giane Gianotto Fernandes, Analistas de Testes
Algumas perguntas surgem quando pensamos em automação de testes: que ferramentas usar? Qual linguagem de programação? O que mais preciso saber?
Mas antes disso, é preciso entender o conceito da automação. Geralmente o primeiro pensamento é que todo projeto deve ser automatizado e que a automação deve cobrir todas as funcionalidades e comportamentos do mesmo. No entanto, é preciso considerar que existem o custo da automação e o perfil do projeto, que podem viabilizar ou não a automação.
Em um projeto onde os requisitos não são muito bem definidos ou que mudam com frequência, a automação dos testes pode não ser recomendada devido a alta frequência de retrabalho. Neste caso, o foco do trabalho passa a ser manter o código de teste atualizado e funcional ao invés de usar os testes para garantir a qualidade do projeto, deixando margem para requisitos não cobertos e falhas na cobertura de cenários.
Uma vez avaliado que cabe automação de testes no projeto, qual seria uma boa estratégia?
Existem ferramentas no mercado que possuem suporte para a gravação do fluxo da interface com o usuário, e que geram o código de teste, por exemplo Appium, muitas vezes tomadas como primeira opção por aqueles que ainda não possuem experiência com automação, que por sua aparente facilidade de uso levam a pensar que se encontrou a solução ideal. Mas olhando mais de perto, ferramentas deste tipo podem causar problemas como dificuldade de leitura, entendimento e manutenção do código gerado, e à medida que o projeto vai crescendo, estes problemas vão aumentando na mesma proporção. Além disso, algumas destas ferramentas apresentam problemas de instabilidade, acarretando transtornos no dia a dia de trabalho e por consequência seu uso torna-se inviável.
Isto posto, uma estratégia que tem funcionado no nosso projeto é incluir a automação de testes no mesmo ambiente do desenvolvimento, utilizando de soluções nativas . Por exemplo, para automação de testes para mobile, usamos o Espresso para Android e XCode Test para iOS. Já para automação de testes web, usamos o framework Protractor, que não é nativo do Angular, mas foi desenvolvido para atendê-lo.
Entre as vantagens que temos encontrado em adotar esta estratégia, desenvolver os testes automatizados usando a mesma linguagem de programação do projeto é uma delas pois facilita o suporte de um desenvolvedor quando necessário. Outra vantagem é a facilidade em configurar a execução dos testes automatizados em ambiente de integração contínua. E ainda outra vantagem é iniciar a automação de testes bem cedo, praticamente a partir da criação da estrutura do projeto, sem a necessidade de esperar por uma primeira versão do projeto para depois começar a testar; os bugs podem ser encontrados e corrigidos mais cedo, com custo menor.
Toda estratégia de testes automatizados traz um grande ganho para qualquer projeto, principalmente pela resposta rápida que fornece sobre a qualidade do produto em desenvolvimento, principalmente se os testes forem executados em ambiente de integração contínua. Mas se a estratégia de testes automatizados for baseada apenas em testes end-to-end, com foco na interface com usuário, ela resultará em problemas como ter testes automatizados complexos, porque será preciso testar as regras de negócio e a camada de serviços a partir da interface com o usuário. Testes complexos significam no mínimo testes difíceis de manter. Além disso, o tempo para execução destes testes ainda será longo, aumentando em muito o tempo de build do projeto, para citar apenas um exemplo.
Para melhorar a estratégia de testes em uso, notamos a necessidade de incluir os testes unitários e os testes de integração (ou testes de serviço, ou testes de API) como parte do esforço de testes, naquela velha ideia do “dividir para conquistar”. Desta forma, o esforço de teste fica dividido entre testers, responsáveis pelos testes instrumentados (ou testes end-to-end), e os desenvolvedores, responsáveis pelos testes unitários e testes de integração. Faz muito mais sentido testar as regras de negócio e as chamadas de serviço nos níveis abaixo da interface com o usuário, pois estes testes são muito mais rápidos para serem executados no nível do código do que no nível dos testes instrumentados. Assim, adquirimos uma resposta mais completa sobre a qualidade do produto. Percebemos também que é essencial manter uma boa comunicação com o time de desenvolvimento, para definir juntos a melhor maneira para cobrir um determinado requisito.
Para exemplificar como a estratégia de testes automatizados fica mais robusta com a inclusão de testes unitários, suponha que em um projeto seja necessário validar as entradas de um campo para informar um CNPJ. Uma abordagem possível seria desenvolver testes instrumentados para todas as entradas válidas e todas as inválidas. Mas uma abordagem melhor seria desenvolver testes instrumentados para testar uma entrada válida e uma inválida, observando o comportamento da interface e verificando as possíveis mensagens de erro, mas testar todas as entradas inválidas através de testes unitários, no nível do código,sem a necessidade de testar através da interface. Desta forma, é possível pensar em outros cenários em que os testes unitários e de integração forneceriam um alicerce sólido para o desenvolvimento dos testes instrumentados.
Uma abstração para uma boa estratégia de testes automatizados é pensá-lo como uma pirâmide: na base encontramos os testes unitários em maior quantidade por conta de seu baixo custo de implementação e execução, seguidos pelos testes de integração na camada intermediária, para testar as chamadas de serviços e APIs e, por fim, os testes end-to-end na sua última camada, em menor quantidade focando os fluxos principais do sistema e os feedbacks de interface, dado seu maior custo de desenvolvimento.
Bibliografia:
MIKE, Wacker. Just Say No to More End-to-End Tests. Disponível em:
https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
