Planejamento de testes de software
Mas então, o teste é planejado?
Essa pergunta pode parecer óbvia para nós testadores e talvez também seja para aqueles que trabalham no dia a dia de um projeto de software. Porém é muito comum existir essa dúvida quando falamos das profissões de “Analista de Testes” ou “Testador de Software” para os iniciantes na área.
Sim. Os testes são planejados, e para garantir a qualidade e o sucesso de uma entrega, durante essa fase, existem documentos que auxiliam e direcionam a equipe nas tomadas de decisões. Na prática, os mais utilizados são: Plano de testes, suíte de testes e casos de testes (ou cenários de testes, caso estivermos falando de BDD).
Segundo Bartié (2002) uma breve definição para esses importantes documentos:
Plano de testes: Formaliza a estratégia de testes, contendo informações sobre o escopo de testes, configuração de ambiente, recursos necessários e cronograma de testes.
Suítes de testes: Uma coleção de casos de testes destinados a testar um fluxo para verificar um determinado comportamento.
Casos de testes: Uma especificação detalhada do teste que deve ser repetível, contendo uma ação e um resultado esperado.
Durante a criação do plano de testes, a equipe deve levar em consideração a estrutura da equipe atual e manter o equilíbrio para a execução de cada tipo de teste. Mas, como devo equilibrar meus testes?
Como equilibrar meus testes?
Em 2009, no livro ‘Succeeding with Agile’, Mike Cohn tornou conhecida uma forma para equilibrar a proporção dos testes que devem ser executados em cada etapa do desenvolvimento de software, levando em consideração o custo e a complexidade da execução. Esta forma foi chamada de Pirâmide de Testes (conforme a figura abaixo) e está relacionada com a proporção ideal para a implementação de testes automatizados. No entanto, na prática, esse conceito é muitas vezes invertido.
Para ter equilíbrio no planejamento dos testes é necessário entender o significado de cada camada da pirâmide.
Explicando e classificando cada camada
- Testes de unidade: Tem por objetivo garantir que a menor unidade do sistema seja validada, como por exemplo: métodos, classes, funções. Normalmente são testes realizados pelos desenvolvedores.
- Testes de serviço: São testes realizados nos serviços da aplicação, nas regras de negócios abaixo da camada de “UI”. Normalmente utilizando ferramentas para auxiliar nesse processo, de tal forma, evitando que esse teste seja realizado apenas quando a “UI” estiver sendo validada. Comprovam a efetiva conexão dos sistemas garantindo a integração entre eles.
- Testes de UI (User interface): O objetivo deste teste é focar os esforços nas funcionalidades críticas, em funcionalidades que envolvam aspectos da interface e diferentes dispositivos (browsers, versões de sistema operacional). É neste momento que a jornada de navegação do usuário é reproduzido.
Conforme a figura acima, na base da pirâmide de testes automatizados se tem um espaço maior para os testes de unidade, onde, o principal esforço deve ser realizado, por conta de ter um baixo custo para implementação e execução. Na camada intermediária se tem uma quantidade média para testes de integração ou de serviços. E por fim, no topo e em menor quantidade os testes de UI, focando nos principais fluxos do sistema.
Conforme a figura abaixo, adiciona-se um espaço para testes manuais, logo após os testes de UI, aqui entram aqueles testes que não são passíveis de automação.
Quando o conceito da pirâmide é invertido, ganhando um formato de ice cream (sorvete) conforme a primeira parte da figura acima, os planos de economizar tempo, dinheiro e de colher resultados positivos nas entregas de software, são destruídos.
Portanto, quando existe equilíbrio e um correto planejamento dos testes, não é necessário automatizar testes exaustivos através da UI, nem reservar muito tempo para testes manuais, pois muitos fluxos são cobertos nos testes de unidade e de integração/serviço. Ainda, durante os testes manuais é possível que o testador consiga mais tempo para explorar o sistema, encontrando e focando em cenários mais complexos.
Acredito que ao adotar a estratégia proposta na pirâmide de testes é possível atingir com mais qualidade e agilidade os objetivos do projeto. Tendo estabilidade nas funcionalidades, já que o custo para manutenção dos testes automatizados é reduzido e a execução se torna mais frequente. E, também é possível a redução do tempo de envolvimento de cada membro da equipe com retrabalho, já que os problemas são encontrados mais cedo. Por fim, com o planejamento e equilíbrio correto dos testes, é possível que a equipe de testes fique focada nos cenários complexos funcionais, garantindo o funcionamento correto do sistema.
Referências:
BARTIÉ, Alexandre (2002). Garantia da Qualidade de Software. 5° ed.
http://blog.myscrumhalf.com/2014/03/melhorando-sua-estrategia-de-testes-automatizados/
https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
