Existem diversos tipos de testes de software e eles são dividido em três principais categorias: Unitários, de integração e ponta a ponta.

Os testes, muitas vezes esquecidos ou até desprezados, fazem parte do desenvolvimento de todo software que se preze. Se uma falha acontecer na mão de um usuário, você não terá chance para se explicar. E assim, o negócio de alguém pode estar em risco por uma simples bobagem feita no código. Então, a melhor forma de garantir a qualidade do aplicativo que você está fazendo é testando ele.

Mas, afinal, de quem é a responsabilidade de testar a aplicação? É do desenvolvedor? Do analista de teste / tester (responsável por encontrar erros, falhas, bugs e outros tipos de problemas que não foram detectados durante o desenvolvimento de um software)? Do gerente de projeto / PO (profissional responsável por priorizar as atividades que maximizam o valor do produto e garantir o retorno do investimento)? A resposta é: todos. Sim, todos devem testar a aplicação, desde o início do desenvolvimento.

Para evitarmos futuras dores de cabeça e correções relâmpago, a equipe de desenvolvimento de software faz (ou pelo menos, deveria) testes em todas as aplicações produzidas. Testes de software são divididos primariamente em três categorias: unitários, de integração e ponta a ponta.

• Testes unitários são feitos em partes isoladas do código, para cada componente. É como se testássemos cada “peça” de um aparelho antes de colocá-las. Vamos pensar que estamos montando um carro. Para garantir a segurança e evitar erros antes de unir todas as peças, é preciso testar cada uma delas separadamente. Por exemplo, para ter certeza que o veículo está funcionando normalmente antes de ir para o mercado, você tem que testar separadamente o freio, o volante, o câmbio, etc.
• Testes de integração são testes unitários feitos em mais de uma parte do código. Eles juntam múltiplos componentes (normalmente 2) e verificam a comunicação e integração entre os mesmos. Este é o teste que garante que a ligação entre as peças está funcionando. Pense no caso do carro novamente: quando você utiliza o volante para dirigir-lo, a roda tem que responder ao pedido e mover o automóvel.
• Testes de ponta a ponta são testes que validam todo tipo de comportamento possível dentro da aplicação, ou seja, simulam a atividade do usuário final. Se usarmos o exemplo do carro, esse tipo de teste seria dirigir o veículo após tudo estar finalizado, como se fosse o usuário normal. Garantindo assim que todas as peças do produto final e as comunicações entre elas estão funcionando corretamente.

Apenas os testes de ponta a ponta bastam?

Ora, mas se testes de ponta a ponta simulam um usuário real, então, em teoria, é a melhor escolha:

1. O desenvolvedor fica feliz, afinal a responsabilidade de testar não é dele
2. O analista de teste fica feliz, pois consegue testar simulando um usuário real, então seus testes de software são mais valiosos
3. O gerente do projeto / PO fica feliz, pois isso vai garantir que o usuário final terá uma experiência melhor

MAS, infelizmente, não é bem assim que funciona. Se dependermos apenas de testes de ponta a ponta, o procedimento ficaria algo mais ou menos assim:

1. O desenvolvedor faz uma feature/versão e passa para o tester do seu projeto
2. Se o tester encontrar algum bug, ele cria um relatório do erro, e o desenvolvedor é notificado
3. O desenvolvedor verifica o erro, checa o código, e corrige o bug
4. Após toda a validação, uma versão de produção é lançada e enviada ao cliente

O que foi vantajoso nesse processo?

• Erros que afetariam diretamente o usuário final foram detectados e corrigidos.

O que houve de errado nesse processo?

• Os desenvolvedores tiveram que esperar o relatório de bugs para poder resolvê-los;
• Bugs pequenos podem estar escondidos atrás de bugs maiores;
• Encontrar a causa dos bugs pode levar um bom tempo.

Obtenha um procedimento mais efetivo

A melhor forma de conseguir sucesso durante o processo é utilizando testes unitários:

Testes unitários são testes de software feitos em partes isoladas do código, verificando métodos e funcionalidades específicas de um componente. Por estarem isolados, é muito mais fácil encontrar e corrigir erros. São testes rápidos e confiáveis.

O grande problema dos testes de software de ponta a ponta é a espera – você não sabe do erro até que ele ocorra na mão de um possível usuário, ou seja, quando já é tarde demais. Testes unitários conseguem ser precisos, ou seja, você sabe o que deu errado com mais precisão, sem esperar chegar ao usuário.

Apesar de todas essas vantagens, há uma coisa que o teste unitário não faz: simular um usuário real.

Evite possíveis bugs

A melhor maneira de nos prevenirmos contra bugs no desenvolvimento é utilizar cada teste corretamente e também usar o nosso tempo durante este processo de forma mais eficiente.

Por isso, utilizamos a pirâmide de testes de software proposta pela Google:

A sugestão é que se faça uma divisão de 70/20/10, ou seja:

• 70% de testes unitários;
• 20% de testes de integração;
• 10% de testes de ponta a ponta.

Isso serve para tentar sempre evitar uma pirâmide invertida (focada em testes de ponta a ponta), ou em formato de ampulheta (foco em testes unitários e ponta a ponta, mas nenhum em integração).

Texto: Leonardo Miyagi
Imagem: Rafaela Brum

*Este texto foi baseado em um artigo publicado pela própria Google, falando sobre testes de ponta a ponta (End-to-End Tests): https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html