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.
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.
Reforço que os testes que estamos expondo aqui são executados em um ambiente de desenvolvimento fora do Android Studio. Se o UI Automator já supre sua necessidade com testes end-to-end, fazer testes nessas condições talvez não seja necessário.
Com isso em mente, posso citar duas situações nas quais fazer testes end-to-end fora do Android Studio pode ser útil para seu time:
- Em ferramentas como Appium, diversas linguagens de programação podem ser utilizadas para escrever esses testes end-to-end fora do repositorio Android. Dentre elas temos Java, Python, Ruby, Perl e algumas outras… Se você possui um time de qualidade que possui fluência em outra linguagem de programação e esse time é separado do time de desenvolvimento, fazer testes dessa maneira pode dar mais autonomia a equipe de qualidade.
- Em algumas ferramentas de teste end-to-end, é possível escrever o mesmo teste para Android e iOS. Coisa que não podemos fazer com o UI Automator. Nesse caso precisamos avaliar se fazer testes compartilhados entre plataformas vai ser benéfico ou não para sua equipe.
É importante mencionar, que 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 por parte do time de desenvolvimento. Caso o time de desenvolvimento seja responsável pela manutenção desses testes, para diminuir essa fricção no dia a dia de trabalho recomenda-se deixar todo o processo de execução e preparação 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! Eu não acredito em separação de devs e QAs em times ágeis. Vamos remover essa barreira invisível entre nós. 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 em produção. Até porque o Proguard pode introduzir possíveis bugs se não configurado corretamente.
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 suas dependências sejam realmente testadas.
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 também 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 não queremos testar cenários de erro e é muito importante que não impactemos nenhum usuário durante a execução, então muito cuidado se for testar em produção!
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
Tenho a opinião que algumas funcionalidades não conseguem ser 100% testadas automaticamente (pelo menos não hoje em dia). Se queremos testar que uma animação ficou legal ou que uma transição entre duas telas 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.
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 fazer distribuição interna. Outra estratégia menos automatizada seria incluir uma etapa de revisão feita por pessoas de UX ou de 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. Espero ter ajudado nessa jornada e obrigado!
