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

0 comentários
  1. Bem legal a comparação mas gostaria de deixar uma sugestão. Quando vocês falam: \”Ruby com Calabash, Java com Eclipse e C# com Visual Studio.\”, estão comparando coisas diferentes, Eclipse e Visual Studio são apenas IDEs. A comparação certa seria \”Ruby com Calabash e Appium em Java e C#.\”

    1. Oi Samanta,
      Muito obrigado pela sua contribuição 😉
      Na verdade o que queriamos dizer foi que com o calabash usamos a linguagem Ruby para escrever os testes, no Visual Studio usamos C# e no Eclipse usamos o Java.
      E tanto no C# quanto no Java usamos o Appium. A IDE que utilizamos para o Ruby é o RubyMine.

      1. Eu de exemplu nu pot instala bitdefender 2013 la care am licenta pe windows 8,deoarece dupa restart ramane ecranul negru…are ceva cu placa video sau cu driverul video…Am incercat de doua ori,acelasi rezultat…Apoi am bagat ka3nprsky,eorton&#82s0;nici un fel de problema…

    2. Zucchini is very popular in this house and we thoroughly enjoy their prolific season. What could be better than zucchini and pasta?? This looks wo!fordulnxexo Pattie

  2. Fala Letícia muito bom o texto, só queria deixar alguns comentários:
    – A comparação de \”Ruby com Calabash, Java com Eclipse e C# com Visual Studio.\” O calabash é um framework de automação mobile e o Eclipse e VS são IDES, que portam utilitários para teste.
    – Quando você comenta sobre o calabash perder o contexto fora da aplicação eu fico meio desconfortável com isso, você quer testar funcionalidade do seu aplicativo ou testar seu device?
    Talvez numa estratégia de teste os devs possam cobrir isso em teste de unidade (o que faz mais sentido) e não sobrecarregamos os testes de UI com isso ( que são lentos).
    O calabash utiliza comandos adb e algumas coisas do robotium para fornecer os métodos que utilizamos.
    – Sobre os testes ficarem lentos, testaram a possibilidade de utilizar o terminal para executar esses testes? acredito que vocês consigam tirar a dependência de uma IDE para rodar os testes.
    Dúvida:
    – Vocês tem um projeto a parte ou fazem no mesmo projeto dos devs?
    – Vocês também fazem automação IOS?
    Novamente, muito bom o artigo!!!!

    1. Olá Wellington,
      Muito obrigado pelo seu comentário! Creio que sua primeira dúvida seja parecida com a da Samanta, não queríamos passar o Calabash como uma IDE.
      Sobre o contexto, nosso problema é que o App que testamos aciona várias aplicações nativas do Android, como câmera, popup e etc. Se tiver alguma sugestão, compartilhe conosco.
      A ideia do terminal é muito legal, mas utilizamos o Calabash por pouco tempo. Nesse caso, não tivemos tempo suficiente para aprimorar o uso da ferramenta.
      No momento estamos trabalhando com aplicativo Android e nosso projeto é a parte, separado dos Dev\’s.
      Compartilhe seu conhecimento com a gente escrevendo um post para o blog. Teremos grande prazer em publicá-lo.
      Um abraço.

      1. Vou deixar meus 10 centavos de contribuição 🙂
        Independente se usar RubyMine, VS, Eclipse, IntelliJ, Sublime, Atom, VIM ou papel de pão e ainda se usa Appium, Calabash com qualquer linguagem, não se apegue a IDE para rodar seus testes, procure sempre uma task do seu gerenciador de dependência como NPM, Gradle, Maven e etc que com certeza você irá conseguir rodar seus testes em linha de comando e consequentemente irá ajudar o DevOps do seu time a integrar seus testes em qualquer que seja a ferramenta de Continuos Integration.

        1. Muito bom Fred, estamos sempre em busca de melhorias, por isso é sempre importante os feedbacks e trocas de informações no Blog.
          Um Abraço!

      2. Sobre o contexto a única maneira é utilizando o que ele faz, criar métodos que fazem uso do adb. Podemos conversar mais sobre isso se quiser 🙂
        Para escrever posts como eu faço?
        Muito obrigado pelo feedback do comentário.

    2. I love reading your response stories Ruby! It&;#2178s like dominoes. I knock the first one over. . . I am so pleased the you visit here and add your words. It makes this experience of writing a blog so much richer.

  3. Letícia,
    Boa tarde,
    Gostaria em primeiro lugar parabenizar vocês pelo excelente meetup. Gostaria de saber se vocês utilizam alguma ferramenta para monitorar o consumo de: Dados, Memória e Bateria?
    Att,
    Rivelino

    1. Boa Tarde Rivelino!
      Para monitorar o acesso à rede, já utilizei Wireshark.
      Eu uso aplicativos que fazem esse tipo de medição. Existem vários na Google Play.
      Está no meu backlog estudar ferramentas para ter esses dados mais confiáveis. Assim que começar a usar alguma, compartilho aqui no Blog 😉

  4. Ótimo post! Muito bem explicado, estruturado e com uma ótima visão da aplicação que tu tens ai no projeto! Parabéns!
    Uma sugestão para um próximo post que me ocorreu: comprar, na visão de utilização do teu projeto, os prós e contras das duas ferramentas (Calabash e Appium).
    Abraços!

  5. Interessante o caminho iniciado e onde ficou o resultado.
    Acho que nem preciso comentar sobre os comparativos com IDE..
    Acredito que nesse momento não seria uma boa hora de ver como testar com as ferramentas fornecidas por google e apple?
    As duas praticamente fazem a mesma instrumentação que appium ou calabash precisam fazer. O ganho é recursos idle e coisas do genero…Está valendo a \”tentada\”..

    1. Oi, Ramses!
      Obrigada pelo comentário.
      Ainda não utilizamos essas ferramentas fornecidas pelo Google ou Apple. Mas vamos pesquisar sobre e, quem sabe, poderá ser assunto para um próximo post! 😉

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Talvez você goste desses conteúdos também: