O Grande objetivo dos testes automatizados é facilitar o máximo possível a vida do testador, diminuindo as atividades manuais repetitivas que são mais suscetíveis a erros (Ex.: Regras de negócio que validem cálculos), fazendo com que o mesmo tenha mais tempo para focar em outras atividades ou camadas de testes, ajudando ao máximo a Squad em que trabalha, aportando realmente valor como um membro do time. Mais para a frente falaremos sobre algumas técnicas.
Gostamos sempre de enfatizar que a codificação da automação é uma etapa do processo, porém existem muitas técnicas e ferramentas que podemos aplicar para a automação de testes, saindo um pouco dessa mística que teste automatizado é somente testes de front-end, onde um robô faz a ação do usuário sem qualquer sentimento, fazendo apenas o que foi solicitado para percorrer na aplicação desenvolvida.
Agora vamos falar de algumas práticas que executamos em alguns de nossos clientes, tais como pirâmide de testes, Integração, E2E etc.
Pirâmide de testes
Uma das formas mais importantes de pensar estrategicamente em testes automatizados é utilizando o conceito da Pirâmide de testes. Este Conceito consiste em aplicar o maior esforço possível em testes nas camadas mais inferiores da pirâmide, onde na base se concentra os testes mais rápidos e baratos, e subindo de tempo e custo para as próximas camadas.
Fonte: Blog Zup
Teste Unitários
Começando pela camada inferior, onde estão nossos testes unitários, e sim, testes unitários são testes automatizados, quando temos uma suíte de teste unitário com uma cobertura de código próximo de 100%, conseguimos garantir que as classes e métodos desenvolvidos cobrem a maioria dos cenários de testes possíveis da nossa aplicação, evitando assim falhas básicas que poderiam acontecer, como por exemplo uma classe que aceita apenas números tendo que tratar caracteres e consequentemente quebrando a aplicação quando os testes unitários não foram bem desenhados, ai vem a pergunta que eu escuto quase todo dia, “mas o QA não deveria testar esse tipo de cenário?”, e a resposta que eu sempre dou é, “SIM e NÃO”, o QA deveria sim pensar nesse tipo de cenário de teste, e pode acreditar que ele vai testar isso, porém não necessariamente em uma automação, provavelmente em um teste exploratório, mas esse tipo de teste deveria ser apenas um exploratório e não uma automação, o que não acontece normalmente, quase sempre o QA tem que criar esse cenário na camada de integração pois não confia na suíte de teste unitário do desenvolvedor, porem quando o Desenvolvedor se antecipa e cria esse teste, que é muito rápido de ser criado e executado na camada de unidade, ele tem uma redução do seu retrabalho, pois se isso não é testado na unidade, e esse erro é encontrado na camada de serviço, o custo para a correção deste erro, é bem maior do que se o Desenvolvedor tivesse criado o teste unitário. Temos então uma redução do nosso tempo de entrega. Vale ressaltar que a comunicação e maturidade do time faz toda a diferença quando estamos criando uma pipeline de automação de testes, pois o time sabe onde deve aplicar seus esforços.
Teste de integração
A camada do meio é chamada de camada de Integração. Estes testes são um dos mais importantes de serem executados, e aí é onde a maioria dos QAs falham, pois eles acreditam que tem que focar maior parte dos seus esforços na automação do E2E. Quando o QA foca em cobrir os cenários na camada de serviço, passando pelos testes de componente, depois indo para os testes de integração, e por fim os testes de API e contrato, ele tem uma cobertura quase que total das regras de negócio aplicadas no desenvolvimento, fazendo com que a necessidade de aplicação de testes E2E seja apenas na jornada principal do usuário, e claro, é importante sempre fazer os testes exploratórios com foco em comportamentos atípicos dos usuários, vale ressaltar que exploratório só deve ser automatizado em última instancia e em cenários muito específicos.
Nesta camada também podemos trabalhar com chamadas ao banco de dados, nesse caso validando se o sistema está enviando e tendo a interpretação correta do Banco, ou seja, lendo e escrevendo o planejado para tal requisição de forma controlada.
Testes UI(End-to-End)
A camada superior, chamada de camada UI(User Inteface ou Interface do Usuário) basicamente são os testes End-to-End(Ponta a ponta). Nesta etapa, testamos a funcionalidade do começo ao fim. Com esse tipo de teste, podemos simular o caminho total, e se o sistema tiver iteração com usuários também realizamos os testes com todas as integrações que o sistema foi projetado. Levando para o mundo de automação, o teste end-to-end pode ser executado na forma de um teste de aceitação, passando por todos os passos que uma pessoa operando o sistema iria executar. Como tende a ser a etapa mais custosa do time de testes(devido a ambientes, BD, aplicações mais maduras etc.),o foco nesta etapa deveria realmente automatizar as principais funcionalidades de ponta a ponta, garantindo que os fluxos de negócio mais importantes para o cliente estejam funcionando de acordo com o que foi solicitado e não quebrem, porém vemos em alguns locais que isto não ocorre. Já vi times de projeto focados em automatizar até mensagem de crítica nesta fase, fazendo com o que o custo e tempo do projeto fossem extrapolados, gastando um tempo que poderiam ser utilizados nas camadas anteriores.
Fonte: Software
Formas de escrita dos casos para automação
Para que a mágica da automação aconteça, podemos nos apoiar em algumas metodologias para escrever os casos de teste e ter uma maior cobertura e facilidade de intepretação do código pelo time de projeto. Abaixo vamos falar de duas delas, lembrando que são métodos que apoiam a escrita de casos manuais/automatizados e não feitos somente para automatização.
Fonte: Artigo Medium
BDD
BDD, acrônimo para Behavior Driven Development ou desenvolvimento guiado por comportamento, basicamente é uma técnica que utiliza linguagem natural para facilitar o entendimento de todo o time de projeto, tanto PO, quanto DEV e QA do que está sendo realizado. Para Automatização de testes, utilizamos esta técnica para escrever nossos testes de aceitação de acordo com os critérios de aceitação das histórias. Utilizamos o famoso Dado, Quando e Então, como por exemplo:
· Dado uma condição
· Quando faço alguma ação
· Então espero algum resultado
Para automação por exemplo de um end-to-end usando o BDD podemos utilizar o Cucumber como ferramenta de apoio. O Cucumber por sua vez como uma ferramenta orientada por comportamento irá analisar o que temos escrito e nos ajudara a automatizar os processos do teste.
Uma das vantagens do BDD como falamos acima, é facilitar o entendimento de design dos testes automatizados, manuais , melhor entendimento em requisitos ou regras negócios, de uma maneira natural, facilitando o entendimento de todos do projeto, desde PO até QA. Uma das desvantagens que enxergamos é a resistência de algumas pessoas que preferem trabalhar do modo tradicional, com requisitos extensos, Step-By-Step etc…. Outra desvantagem é a maturidade do time. Quando temos equipes que não possuem o conhecimento do negócio ou não estão no mesmo ambiente, torna-se difícil a prática do BDD.
TDD
Aqui temos uma metodologia guiada em desenvolvimento em testes. Foi uma prática trazida do Extreme Programming para ajudar nos testes e sua cobertura. Aqui nós escrevemos os testes antes do desenvolvedor começar a escrever seus códigos e temos algumas premissas:
· Escrever um teste que falha (RED)
· Fazer o teste passar da forma mais simples possível (GREEN)
· Refatorar (Refactory)
Uma das vantagens do TDD é a segurança e melhor projeção de classes do sistema, além do aumento da visibilidade de “Pronto” do sistema, pois como o teste é escrito antes do código, o mesmo é evoluído continuamente devido ao seu circo virtuoso.
Como desvantagem, é uma técnica que está sempre em discussão, pois temos equipes que enxergam vantagem em utilizá-la e evangelistas que dizem o que o mesmo está morto e é irrelevante(TDD is dead. Long live testing)
Conclusão
Em primeiro lugar, podemos concluir que as principais vantagens da automatização de testes é a agilidade e a mudança de cultura. Isso porque testes manuais são demorados e custosos para a equipe de TI e para o cliente final. Porém, quando a automatização é utilizada, o processo pode ser muito mais ágil e simples. Neste artigo, apresentamos algumas técnicas de testes, mas existem as mais variadas e exóticas possíveis, mas isso é papo para um próximo artigo.
Valeu, pessoal!!!! Até a próxima!
