Um papo sobre os desafios do teste em mobile e automação em RUBY, JAVA e C#

Na quinta-feira (25/08), Sthanley e eu participamos do Meetup Café, Testes e Pão de Queijo. Por duas horas, conversamos sobre o tema “Desafios dos testes em mobile” e fizemos também a demonstração da automação dos testes em três linguagens e ferramentas: Ruby com Calabash, Java com Eclipse e C# com Visual Studio.

Este tema já foi abordado aqui no Blog, mas sempre vale a pena reforçá-lo, principalmente com quem está começando a trabalhar com aplicativos.

O DESAFIO DO PROCESSO

O primeiro grande desafio foi o processo adotado no projeto Omni. O nosso prazo era bem apertado, eram apenas três meses para o aplicativo ficar pronto e integrado a uma plataforma desenvolvida aqui na Take. A equipe contava com 15 desenvolvedores e 2 QA’s. Como havia um grande número de dev’s na equipe, várias novas features eram implementadas diariamente. Então, todos os dias era preciso testar as novas features e as features implementadas anteriormente, para garantir que tudo continuasse funcionando. Com o tempo, foi ficando impraticável realizar os testes manualmente. Além dos desafios do processo adotado, tinham os desafios dos testes em mobile, sobretudo no Android!

O DESAFIO DOS TESTES EM ANDROID

Bem, vamos mapear alguns dos desafios encontrados quando o assunto é Android.

Diversidade de fabricantes

teste em mobile

Diversidade de Fabricantes

 

Como podemos ver na imagem acima, temos uma variedade grande de fabricantes. Além dos mapeados no gráfico acima, existem outras marcas ganhando mercado, como Quantum Go, Blu e Alcatel. Na hora dos testes, é preciso cobrir modelos diferentes, já que o app pode se comportar de várias maneiras em marcas diferentes. Um exemplo disso é o Xiaomi!! Em alguns apps, é preciso marcar as permissões manualmente para que o aplicativo funcione. Ele pode até dar crash!!

Diversidade de Sistemas Operacionais

teste em mobile

Diversidade de SO’s

 

É preciso dar muita atenção à diversidade de Sistemas Operacionais. Se o app que você está testando dá suporte a partir da versão 4.0 é preciso lembrar que o Android é muito fragmentado. Será preciso testar as versões 4.0, 4.1, 4.1.2, 4.2.1… e assim por diante. Além da fragmentação, o Android pode variar de fabricante para fabricante, uma vez que eles manipulam o SO para melhor se adequar ao que desejam. Tenha em mente que, uma funcionalidade que se comporta da forma desejada no Android 5.0, poderá não funcionar da mesma forma no Android 4.4.4.

Diversidade de tamanhos de tela

teste em mobile

Diversidade de tamanhos de tela

 

Além dos fabricantes e dos SO’s, há também a diversidade de tamanhos de tela. Bugs de layout são os mais comuns de acontecer caso o desenvolvedor não leve em consideração a resolução de tela na hora da implementação. Abaixo, temos um exemplo de bug de layout caso a resolução da tela não seja considerada.

teste em mobile

Bugs de layout em aparelhos como Pocket

 

Performance

teste em mobile

Top 5 performance draining apps

 

Outro ponto de atenção é com relação à performance do aplicativo que você está testando. É preciso que ele consuma poucos dados, pouca bateria e pouca memória. A não ser que seu app seja o Facebook, Instagram, Spotify… o usuário vai desinstalar o app. Então, na hora dos testes, muita atenção quanto a isso.

Diante desse cenário, me perguntei: Como manter a qualidade sem perder a velocidade? Uma das saídas foi começar a automatizar os testes.

Estou trabalhando a mais ou menos um ano e meio com automação Android. E nesse tempo tive contato com três ferramentas em três linguagens diferentes. Vou falar um pouco da minha experiência utilizando cada uma delas. Minha intenção não é falar que a ferramenta X seja melhor que a Y, pois a escolha da ferramenta deve ser feita conforme a sua necessidade. Mas, claro, tenho lá minhas preferências. :p

CALABASH ANDROID EM RUBY

A primeira ferramenta com a qual tive contato foi o Calabash. É uma ferramenta muito boa para quem está começando, pois o aprendizado é rápido. É possível escrever muitos testes utilizando apenas linguagem natural, já que há vários canned stesps já implementados. Só precisei começar a implementar em Ruby quando acessei aplicativos nativos do Android, como a câmera, por exemplo. O Calabash não “enxerga” as aplicações nativas, então, foi preciso criar os testes através dos keycodes do Android. Funciona muito bem! O problema é que os testes ficavam muito amarrados a um modelo específico. Mas, não dê esta ferramenta como descartada! Caso você precise criar testes que abrangem apenas a sua aplicação e não a nativa, grande chance do Calabash atender a sua necessidade.

APPIUM NO ECLIPSE EM JAVA

A medida que o Omni foi crescendo, o Calabash foi parando de atender as minhas necessidades. Meus testes foram ficando cada vez mais amarrados e com alguns recursos técnicos, conhecidos vulgarmente por gambiarra. Foi a hora de estudar outra ferramenta. No começo, criei até uma certa resistência em mudar, ainda mais porque não sabia programar nem o “Hello World” em Java. Mas, como sou brasileira e não desisto nunca, os testes começaram a sair. Comecei a migrar os testes do Calabash para o Appium e logo percebi uma melhora de desempenho e, além de tudo, os testes estavam menos amarrados. Mas, ainda sim, ela não me atendia 100%. Um dos maiores problemas que enfrentei foram com as esperas. O Eclipse, por motivos obscuros, não respeitava o tempo determinado em alguns testes. Foi aí que comecei a estudar uma terceira ferramenta.

APPIUM NO VISUAL STUDIO EM C#

Devido aos problemas que estava tendo com o Eclipse, comecei a pesquisa uma nova ferramenta. Aqui na Take somos parceiros Microsoft, então, por que não utilizar o Visual Studio? É a ferramenta que estou utilizando no momento e, até agora, não tive problemas. Os testes estão com desempenho melhor, mais rápidos e totalmente independentes. Além disso, o Visual Studio tem um suíte de teste, caso você precise fazer testes de carga e etc.

MINHA HUMILDE OPINIÃO

Das três ferramentas com as quais trabalhei, o Visual Studio em C# é o que mais tenho gostado. Os testes estão mais estáveis e mais estruturados. Mas, de forma alguma descarto as outras ferramentas. Tudo vai conforme a sua necessidade. Calabash é uma ótima ferramenta para testes que não precisem acessar aplicações nativas. É fácil e, muitas vezes, não precisa escrever linhas de código. Se você não tem licença para utilizar o Visual Studio Professional, o Appium no Eclipse funciona muito bem e é uma ótima escolha, apesar do wait das uns “vacilos” as vezes. Mas, se você tem acesso ao Visual Studio Professional, aconselho experimentar criar os testes por aqui! Você não irá se arrepender. Pode ser que amanhã saia uma ferramenta melhor e migre os testes de novo… Mas, por enquanto, VS em C# é a minha indicação.

Até a próxima 😉

 

por Letícia Bomfin