Boas práticas de testes para equipes ágeis: a pirâmide de automação

A automação de testes e o desenvolvimento ágil de software andam de mãos dadas, mas automatizar costuma ser mais fácil de dizer do que de fazer. A maioria dos desenvolvedores reconhece os benefícios da automação de testes: ela acelera os testes, reduz custos, aumenta a cobertura etc., mas muitos nunca passam do investimento inicial necessário para começar.

Como os homens das cavernas desta tirinha, muitas equipes ficam presas a métodos de teste menos eficientes porque acham que não têm tempo para implementar mudanças, quando, na verdade, estão prejudicando a si mesmas. Não caia nesse mau hábito!

Hoje vamos compartilhar com você uma das nossas melhores práticas de testes para equipes ágeis.

Como começar? Como saber em quais áreas focar? Quais casos de teste devem ser automatizados? No desenvolvimento de software não ágil, muitas pessoas acabam caindo sem perceber no “antipadrão do cone de sorvete” nos testes, ao dar mais ênfase à automação no nível de UI.

Na Abstracta, preferimos a abordagem que vira esse cone de sorvete de cabeça para baixo. Concordamos com a abordagem popularizada por Mike Cohn, a pirâmide de automação de testes ágil, que traz o máximo retorno para o seu investimento em automação, melhorando o ROI da automação e garantindo que você obtenha os maiores benefícios da automação.

Quando a maior parte dos nossos esforços se concentra na automação no nível de UI, o foco está em encontrar bugs, enquanto, com a pirâmide ágil, a ideia é preveni-los.

Na figura abaixo, você pode ver como as duas abordagens se diferenciam.

Camada da base: testes unitários¶

Na pirâmide, claramente (como parte das boas práticas de testes para equipes ágeis), a maior parte dos testes deve acontecer na etapa de desenvolvimento, executando testes unitários após cada build.

Esses testes são os mais fáceis, baratos e rápidos de concluir e são um aspecto importante do desenvolvimento orientado a testes. Executar mais testes em um nível mais baixo nos permite “conferir o nosso trabalho” à medida que avançamos, obtendo feedback imediato e sabendo exatamente onde estão os bugs, quando é muito mais difícil para eles se esconderem. Aqui, os bugs também têm uma vida mais curta: nascem e são eliminados em menos de um minuto, talvez.

Durante os testes de UI, os bugs já terão vivido muito mais tempo e vão resistir mais, porque viveram ali muito confortáveis por um período mais longo (talvez até alguns dias).

Camada do meio: testes de API/integração/componentes¶

Depois de executar todos os testes unitários e de eles passarem, podemos seguir para a fase de testes de API/integração/componentes. Os testes de integração são executados para garantir que todos os componentes funcionem bem juntos. É aqui que podemos testar a maior parte da lógica e dos processos de negócio sem passar pela UI. O melhor é automatizar aqui o máximo possível.

Se você precisa decidir entre automatizar neste nível ou no nível de UI, aqui terá menos problemas, manutenção mais fácil, execução de testes mais rápida (o que significa encontrar bugs antes e reduzir a vida deles) e ainda poderá testar a lógica do seu sistema. Esses testes são mais lentos e complexos do que os testes unitários, mas continuam sendo mais rápidos e menos frágeis do que os testes de UI.

Camada do topo: testes de UI¶

Por último, e em menor quantidade, vêm os testes de UI. O melhor é executar o mínimo possível, porque são caros, mais difíceis de preparar e manter e demoram muito. Aqui você só quer ter certeza de que a interface do usuário em si funciona bem, sabendo que todos os outros aspectos do sistema já devem ter sido testados.

Automatize só os testes mais críticos, de ponta a ponta, com um fluxo que começa no login do usuário e termina na sua ação final, como a mensagem de sucesso da transação. Também é útil focar em aspectos ligados aos navegadores ou à UI. Tenha cuidado com esses testes, porque são mais propensos a gerar falsos negativos e falsos positivos. Depois dos testes de UI, podem ser feitos testes manuais e exploratórios (como mostra a esfera acima da pirâmide).

Como você pode ver, a abordagem da pirâmide é uma forma mais sólida, vantajosa e econômica de implementar a automação de testes do que concentrar o foco em testes automatizados de GUI e seguir sem perceber o “antipadrão do cone de sorvete”. A pirâmide oferece uma base sólida na fase de testes unitários, sobre a qual se constroem os testes seguintes nas fases de integração e de UI, enquanto a abordagem do cone de sorvete é mais “pesada no topo” e menos estável.

Para se destacar no mundo do desenvolvimento ágil, é imprescindível seguir a pirâmide de automação de testes para produzir o software de melhor qualidade possível.

Não acredite só na nossa palavra! Até os testers do Google dizem que este é o melhor método.

Você já experimentou? Conte para a gente nos comentários!

Recomendados para você¶

Os 4 desafios mais comuns da automação de testes (e como superá-los) Como evitar falsos positivos e falsos negativos na automação de testes