TESTES AUTOMATIZADOS
1 - Tipos de Testes
Na última semana apresentei aqui na empresa para alguns convidados uma introdução aos testes automatizados de software. Para quem ficou curioso, fiz uma série de posts com o conteúdo da apresentação, que compilarei aqui como um só.
Para entender o contexto dos testes automatizado, primeiro é importante entender a diferença entre tipos de teste.
Pelo tipo, podemos classificar os testes em:
· Testes de funcionalidade: Verifica se determinada funcionalidade tem o comportamento esperado. Um exemplo é um teste que tenta gerar a segunda via do boleto. O testador clica no botão de segunda via e verifica se o sistema gerou o arquivo corretamente.
· Testes de usabilidade: Verifica características não-funcionais de usabilidade. É mais usado para compreender e melhorar a interação do usuário com o software, do que para ‘encontrar erros’. Valida questões como: Satisfação subjetiva dos usuários com o sistema e Facilidade de aprendizado para uso do sistema.
· Testes de segurança: Avalia as vulnerabilidades do software para determinados tipos de ataques.
· Testes de performance ou desempenho: Avalia se o sistema atende requisitos de tempo de resposta, tempo para entrar em funcionamento e volume de uso.
Pela técnica empregada, podemos classificar em:
· Teste funcional: black box, olha por fora mas não se importa com a estrutura interna. Tem por objetivo garantir que os requisitos e as especificações do sistema tenham sido corretamente implementados.
· Teste estrutural: White box, olha por dentro, tentando garantir que a estrutura esteja correta. Tem como foco averiguar o comportamento do sistema em determinadas situações garantindo que o software funcione no contexto técnico onde serão instalados.
Pelo nível em que o teste ocorre, podemos separar em:
· Teste de unidade: Verifica uma unidade (a menor parte do software) para garantir que tem o comportamento esperado. Neste tipo de teste, a unidade é testada de forma isolada, sem considerar nenhuma dependência ou integração. Geralmente significa invocar um método passando determinadas entradas e então validar se a saída está correta.
· Teste de integração: Verifica que uma unidade tem o comportamento esperado quanto funciona integrada com as partes das quais depende. Pode verificar a integração entre uma classe e o banco de dados, entre um módulo e um web service, etc.
· Teste de sistema: Verifica se o sistema como um todo tem o comportamento esperado. Esse tipo de teste não está interessado nas partes e no comportamento individual das unidades, mas sim no resultado do todo. É um tipo de teste ‘black box’.
· Teste de aceitação: É o mesmo que o teste de sistema, mas geralmente mais superficial, se preocupa em dizer se o sistema atende os requisitos mínimos para ser aceito, olhando o todo de forma ‘black box’.
2 - Problemas do Teste Manual
Dando sequencia, vamos discutir algumas falhas do teste manual.
Pra começar, como funciona o teste manual?
O teste funcional manual é executado por uma pessoa que utiliza o sistema, executando manualmente uma série de fluxos planejados (conhecidos como casos de teste ou cenários de teste).
Nessa forma de trabalho, geralmente um Testador mais experiente escreve os casos de teste, que podem ser registrados em uma ferramenta como o Testlink, por exemplo. Depois, a cada versão disponível ou alteração feita no sistema outro testador executa esses fluxos planejados, verificando se o sistema gera a saída esperada para cada ação executada.
E a cobertura, como fica?
Neste ponto é importante pensarmos no conceito de cobertura: Um software é formado por muitas funcionalidades e elementos. A cobertura do teste é o percentual de funcionalidades e elementos que são testados ao se executar determinado conjunto (ou suíte) de testes.
No teste funcional manual, por mais que o planejamento dos cenários seja muito bem feito e com ótima cobertura, a cobertura da execução depende totalmente do EXECUTOR a cada execução.
Problemas conhecidos
· Testadores viciam! Quando uma pessoa passa muitas vezes pelo mesmo fluxo, pela mesma tela, pelo mesmo botão, acaba “viciando”. Esse termo é usado para dizer que a pessoa já não dá mais a mesma atenção para aquele teste como deu na primeira vez que executou.
· Testadores acordam de mal humor as vezes… Outras vezes estão com sono, e outras vezes ficam doentes. Em resumo, depender de uma pessoa e de sua atenção é uma chance de falha enorme.
· Teste manual é lento demais para fluxos de entrega contínua ou para problemas em produção. A questão aqui é regressão, ou seja, a realização de testes em partes do sistema que já estavam prontas e testadas, e que teoricamente nem foram alteradas.
A melhor forma de ter segurança em produção é executando testes de regressão a cada alteração. O problema é a viabilidade de custo e tempo para realizar estes testes cada vez que uma feature é incluída ou que um defeito é corrigido.
Em resumo, o teste funcional manual não é muito confiável quando dependemos apenas dele para testar TODO o sistema e garantir a regressão em cada alteração.
Além disso, o teste funcional sozinho é perigoso, e deveria ser combinado com testes de unidade para garantir que as partes estão funcionando.
Comparação
Cada tipo de teste tem suas vantagens, confira:
Por todas as falhas do testes manual e pelas características de cada tipo de testes, é recomendado que se usem testes manuais apenas para ‘pensar’ naquelas situações complexas ou inesperadas, gerando novos testes automatizados quando encontrá-las.
Recomenda-se ainda uma quantidade significativa de testes funcionais automatizados, para poder realizar testes de regressão rapidamente, garantindo o funcionamento do sistema após alterações.
Por fim, essa estrutura tem que ser baseada em uma grande quantidade de testes unitário, que garanta que as parte estão corretas.
Infelizmente, a realidade normalmente é o contrário!
3 - Exemplo de Teste Automatizado:
O objetivo é desmistificar os testes funcionais automatizados com um exemplo bem simples da estrutura necessária para os testes.
Ferramentas e técnicas
Algumas ferramentas e técnicas adotadas aqui na empresa são:
· Selenium WebDriver
· Headless testing
· Page Object
· JUnit
· Cucumber (BDD)
Exemplo
A estrutura da suíte de testes funcionais está dividida em features, steps, interactions e pages. A figura abaixo é um print dessa estrutura criada na IDE Eclipse com plugin do Cucumber.
Feature
Nessa estrutura, a feature começa com a descrição da história de usuário.
Para cada feature, podemos escrever vários cenários de testes, que são escritos no formato clássico do BDD.
O cenário representa um fluxo de uso do sistema, explicitando entradas e saídas. Os dados que serão usados na entrada ou que devem ser validados na saída podem ser parametrizados, como no exemplo abaixo.
Steps
O Cucumber interpreta o cenário escrito em linguagem natural e gera a classe com os métodos que representam os steps do cenário.
O testador só precisa completar cada método com a ação que deve ser tomada (interaction).
Interactions
A classe de interactions é o primeiro nível em que realmente há alguma “programação”. Aqui o testador tem que implementar as interações, através de chamadas de métodos dos componentes da tela.
Page
Para poder invocar métodos dos componentes da tela, o testador tem que mapear o PageObject, que é um objeto que representa a estrutura da tela. No exemplo abaixo, é feito o mapeamento do campo “email” pelo id que o campo tem na página.
Visão geral
Este post mostrou os vários níveis da estrutura de um teste funcional automatizado com Selenium, Cucumber e PageObject.
A intenção foi demonstrar que o testes automatizado não é nada de outro mundo, e com as ferramentas corretas pode ser facilmente implementado.
Pra fechar, a figura abaixo mostra um ciclo inteiro:
4 - Como começar a automação
Geralmente essa dúvida surge em casos de sistemas legados, em que já se vive a situação de falhas constantes em produção, lentidão para corrigir e outras reclamações comuns.
Nesses casos a automação pode ajudar? Por onde começar??
Comece com testes funcionais, não com unitários
Realizar testes unitários significa verificar cada parte, em separado, para verificar se tem o comportamento esperado. Em um software, isso pode significar escrever um teste que valida cada método do código fonte.
Com teste unitário, demoraríamos muito tempo para ter uma boa cobertura de um sistema legado, além de exigir um alto conhecimento da estrutura interna do sistema e em alguns casos exigir refactor.
O refactor se faz necessário porque em alguns casos o código fonte está muito acoplado e precisamos primeiro “separar” as unidades, para depois testá-la.
Por estes motivos, projetos para escrever testes unitários para sistemas legados costumam acabar em frustração.
O ideal é começar por testes funcionais. Com uma quantidade bem menor de testes é possível cobrir muito mais funções do software, não há necessidade de conhecer a estrutura interna e a chance de precisar de refactor é muito menor.
Comece com os fluxos principais de uso
Mesmo para começar a construir testes funcionais, é necessário planejar uma estratégia, já que não é possível automatizar todas as funcionalidades de uma vez só.
A sugestão é identificar os fluxos principais da aplicação, aqueles que tem mais impacto para o negócio ou para o dia-a-dia dos usuários, usando o conceito de ‘smoke test’.
Em uma loja on-line, por exemplo, o primeiro fluxo para automatizar poderia ser o fluxo no qual um usuário busca um produto, insere no carrinho e finaliza a compra. Este fluxo é muito mais crítico para o negócio do que os cadastros ou relatórios administrativos.
Não reinvente a roda
Outro motivo de frustração em projetos de automação de testes é tentar reinventar a roda, adaptando ferramentas que já são usadas na organização para que façam outras coisas.
Para o sucesso da sua automação, escolha ferramentas sólidas, avalie a adoção dessas ferramentas pela comunidade de desenvolvimento e o quanto de ajuda você poderá encontrar na Web.
Entenda que você precisará de conhecimento nas ferramentas de teste, e precisará ainda conhecer um pouco de DevOps para que as automações de testes sejam mais úteis.