Explorando a pirâmide de testes no Android — Testes end-to-end e manuais — parte 4

Essa é a parte final da série de posts sobre pirâmide de testes no Android. Anteriormente dei uma introdução sobre os conceitos e logo após falei sobre a base da pirâmide e testes instrumentados. Dá uma olhada se você ainda não viu 😄

Nessa parte falaremos sobre a camada mais alta da pirâmide. Nela se encontram os testes automatizados end-to-end, que são testes que têm como objetivo testar que um fluxo está se comportando de maneira adequada do início ao fim. Nesse tipo de teste normalmente utilizamos algum tipo de serviço remoto ou banco de dados real para testar a comunicação da app. Por esse motivo, os testes end-to-end são considerados os mais caros, lentos e de difícil configuração, contudo, possuem um valor muito alto por testarem praticamente todas as integrações da aplicação e por se aproximarem muito de um ambiente de produção.

Exemplo de pirâmide de testes no Android com foco no topo

É interessante mencionar que esses testes que estamos expondo aqui são executados em um ambiente de desenvolvimento fora do Android Studio. Outro detalhe é que diversas linguagens de programação podem ser utilizadas para escrever esses testes. Por exemplo o Appium suporta testes end-to-end em Java, Python, Ruby, Perl, dentre outras…

Por estar em um ambiente fora do seu projeto Android e por possivelmente utilizar uma outra linguagem, pode existir muita resistência na criação desse tipo de teste. Para diminuir essa fricção no dia a dia de trabalho, recomenda-se deixar todo o processo de execução dos testes e preparação do ambiente o mais automatizado possível.

Adicionalmente, devemos ter em conta que esses testes dependem de uma APK já construída, por isso é muito importante ter os comandos ADB e Gradle do Android bem internalizados no time para facilitar a execução dos testes.

Lembrete: Idealmente todas as pessoas que desenvolvem software no seu time deveriam ser responsáveis pela criação dos testes em todas as camadas da pirâmide! Vamos tirar essa barreira invisível entre devs e QAs. Peace ☮️
Lembrete II: Se seu projeto faz uso de Proguard. Busque fazer seus testes end-to-end sempre com uma APK ofuscada para se aproximar o máximo possível da app que será utilizada pelos usuários. Até porque o Proguard pode introduzir possíveis bugs se não configurado corretamente.
Lembrete III: O UI Automator, que foi mencionada no post passado, também pode ser usado para construir testes end-to-end.

Categorias de teste end-to-end

Feito essa introdução sobre testes end-to-end. Eu gostaria de categorizar três tipos de teste que tive oportunidade de trabalhar durante minha jornada como desenvolvedor:

#1 Testes em ambientes pré-produção

Esse é o tipo de teste end-to-end mais tradicional. Nesse caso nós podemos compilar nossa APK para que aponte a um endpoint ou base de dados em um ambiente diferente de produção. Esse endpoint ou base de dados pode estar em um ambiente diferenciado que normalmente chamamos de integração, QA, pré-prod ou mocked, independente do nome, o importante é que a comunicação com sua dependência seja realmente testada.

Existem várias estratégias para facilitar a construção desse tipo de teste, uma delas seria fazer uso de build flavours no projeto Android para apontar para ambientes diferentes na hora de compilar sua APK.

#2 Testes de migração

Esse tipo de teste é mais utilizado quando fazemos uso de bibliotecas de base de dados no Android como Room ou Realm. Apesar de existirem testes instrumentados específicos para essa situação, em uma camada end-to-end conseguimos testar uma migração completa de maneira bem fiel.

Abaixo temos um passo a passo de como construir um teste de migração completo. O que fazemos é basicamente "simular" uma atualização de versão da app:

  • Compilar uma APK na versão 1
  • Instalar APK 1 em um aparelho ou emulador
  • Fazer algumas interações que armazenem dados dentro da app utilizando Appium ou outra ferramenta de preferência
  • Compilar uma APK na versão X, que seria a mais nova versão a ir a produção
  • Atualizar a APK da versão 1 para a versão X no aparelho sem apagar os dados que foram previamente inseridos. Para isso podemos utilizar o comando "adb install -r apkname.apk"
  • Por último, verificar que os dados permanecem consistentes depois da atualização

#3 Testes de fumaça (Smoke tests) 🚒 👩‍🚒 👨‍🚒

Os testes de fumaça ou smoke tests são testes muito simples que garantem o funcionamento mínimo da aplicação em um ambiente que seja o mais real possível. É muito comum encontrarmos esse tipo de teste apontando para um ambiente de produção. Ele literalmente serve para identificar que não tem nada em chamas 🔥 e que as dependências mais importantes estão operantes.

Nesse tipo de teste dificilmente testamos cenários de erro e é muito importante que não impactemos nenhum usuário durante a execução, então muito cuidado!

Existem várias lendas para a expressão "Smoke Test". Uma delas diz que o termo foi originado no desenvolvimento de hardware, onde as pessoas "cheiravam" o circuito ao fazer um teste, se cheirasse a queimado algo ruim tinha acontecido. Outra teoria é que encanadores utilizavam fumaça dentro dos encanamentos para buscar vazamentos, se alguma fumaça fora do padrão fosse identificada "vazando" por fora do cano, aquele encanamento estaria com problemas. Vai entender….

Testes manuais [Bônus]

Tenho a opinião que algumas features não precisam ser 100% testadas pela máquina (pelo menos não hoje em dia). Se queremos testar que uma animação ficou legal entre os vários aparelhos suportados pela app, ou que uma transição entre uma tela está funcionando como esperado, dificilmente um teste automatizado vai cobrir esse requisito de maneira eficiente. Por isso acho que em alguma situações no desenvolvimento mobile não podemos escapar dos testes manuais.

Exemplo de pirâmide de testes no Android com foco na parte manual

Para facilitar o processo de teste manual podemos seguir algumas estratégias, uma delas é ter uma etapa na pipeline de entrega para publicar uma versão da app para alfa ou beta testers antes de sair a produção, se sua equipe não tem acesso ao google play ou não possui permissão para fazer isso, o Hockey App também pode ser utilizado para distribuição interna. Outra estratégia menos automatizada seria incluir uma etapa de revisão feita por pessoas de UX ou negócio antes de algum release.

O importante é que essas etapas façam parte do processo de desenvolvimento e que várias pessoas do time também possam ser incluídas independente da função.

FIM

Se você chegou até aqui, gostaria de te dar os parabéns 👏 Você acaba de adquirir o conhecimento para construir sua própria pirâmide no Android. Feedbacks também são muito bem-vindos, qualquer dúvida ou sugestão pode entrar em contato nos comentários! Obrigado!