Desenvolver e validar aplicativos para dispositivos móveis é um grande desafio devido as variações de sistemas operacionais, fabricantes, tamanhos de telas, customizações feitas pelos próprios fabricantes e pelos usuários, além da intermitência das redes de telefonia móvel que prejudicam de forma significativa a comunicação dos aplicativos com seus servidores e serviços. No entanto, a maioria das organizações validam seus aplicativos apenas com atividades de testes tradicionais manuais e automatizadas, deixando de lado uma das atividades de testes mais importantes no processo de validação de aplicativos para dispositivos móveis: os testes em campo.

Os Desafios da Plataforma Mobile

Chris Karnacki e Rachel Obstler, durante o Webinar da Keynote realizado em 2016 [1], afirmaram que no ano de 2015 havia cerca de 24.000 variações de dispositivos Android no mercado, evidenciando a necessidade de codificação de scripts automatizados para validar funcionalidades, regras de negócios, fluxos e requisitos no maior número possível de dispositivos móveis. Obviamente esse processo de validação deve estar dentro de uma estratégia de testes adequada para cobrir o maior número de dispositivos móveis que serão ou são utilizados pelos usuários finais. Ainda segundo eles, no ano de 2015 foram realizados cerca de 227 bilhões de downloads nas lojas virtuais e somente 16% dos usuários estavam dispostos a dar mais de uma chance para um aplicativo de baixa qualidade.

Se a experiência do usuário com o aplicativo móvel é ruim, ele simplesmente apagará o aplicativo de seu dispositivo e procurará alternativas para solucionar seu problema ou mesmo realizar suas tarefas utilizando o serviço em outras plataformas (Ex. plataforma WEB), optando até por um aplicativo similar de um concorrente, etc. Mas tenha certeza, antes de fazer isso, o usuário deixará registrado sua insatisfação nas lojas virtuais e diminuirá o rating do aplicativo, levando a reputação da organização para baixo. Esses comentários, além do rating, influenciam de forma significativa a decisão de outros usuários de baixar o aplicativo.

É importnante ressaltar que existem diversos fatores que podem estar associados a sistemas de baixa qualidade, conforme descritos no artigo intitulado “O sistema funciona no ambiente de desenvolvimento, mas depois de publicado os usuários começam a achar falhas. Isso é familiar para você?”[2]. No entanto, ainda que os testes tradicionais manuais e automatizados sejam atividades de testes imperativas no processo de validação de aplicativos móveis, é necessário ir além dessas atividades para evitar que os usuários encontrem falhas nos aplicativos.

O Ambiente de Testes nas Organizações

A validação de aplicativos móveis nas organizações segue praticamente o mesmo ritual. Depois de liberada uma versão pela equipe de desenvolvimento, os analistas de qualidade executam uma séria de testes manuais e/ou automatizadas nos emuladores, simuladores ou dispositivos físicos reais, sendo os dois primeiros uma abordagem pouco (ou nada) eficiente.

É importante ressaltar também, que por questões políticas ou burocráticas das organizações, muitos analistas, e talvez muitos desenvolvedores, executam atividades de desenvolvimento e testes nos seus próprios dispositivos móveis pessoais. Em outras ocasiões, utilizam dispositivos da empresa que geralmente não estão sendo utilizados em outros projetos ou por outras equipes, destruindo a estratégia de testes, uma vez que a seleção dos dispositivos móveis deve estar baseada naqueles que estão sendo mais utilizados pelos usuários do aplicativo ou aqueles mais difundidos no mercado (“como fazer a seleção desses dispositivos fica para um próximo artigo”).

Essa abordagem ou estratégia é bem representada na história do “cobertor curto”. Sempre que a equipe cobre a cabeça, os pés ficam descobertos e vice-versa. Ou seja, enquanto o aplicativo funciona em um range de modelo/sistemas operacionais, para de funcionar em outros e vice-versa.

A imagem abaixo é um exemplo de um ambiente para validação de aplicativos móveis, utilizando dispositivos reais conectados em diversos servidores, e acessados através de ferramentas de interface para modelagem e execução de scripts automatizados ou testes manuais.

No entanto, por mais que esses ambientes de testes sejam perfeitos ou não, as atividades de testes nas organizações são executadas em ambientes controlados, pois nos laboratórios tudo funciona perfeitamente (“ou deveria funcionar”). O ambiente de testes das organizações não é o mesmo dos usuários. Se algo não está funcionando na organização, existe uma equipe de TI que irá fazer funcionar. Geralmente, as ferramentas estão no ar, a banda larga corporativa é rápida, os dispositivos estão atualizados, os SIM Cards possuem plano de dados e se a rede de telefonia móvel está ruim em determinado local do laboratório, a equipe se muda para um ambiente melhor, “com mais sinal”. Esse cenário está muito longe do ambiente real dos usuários finais.

O Ambiente dos Usuários

De acordo com a Associação Brasileira de Infraestrutura para Telecomunicações (ABRINTEL), seria necessário triplicar a quantidade de torres para atender a demanda de conectividade de dispositivos móveis na cidade de São Paulo [3]. Essa demanda está associada a áreas que não possuem cobertura de sinal das operadoras, antenas com tecnologias ultrapassadas, sobrecarga nas antenas em bairros ou áreas de grandes aglomerações de pessoas como estádios de futebol, shows, shopping centers, aeroportos, bairros muito populosos, etc.

Esse estudo corrobora com a imagem abaixo. Esse mapa é uma representação das áreas de cobertura 4G da operadora de telefonia móvel TIM [4] e de seus serviços na zona leste de São Paulo em 2018. A cobertura 2G e 3G seguem o mesmo padrão. Além da disposição das antenas no mapa (ex.: uma única antena para atender uma grande área), perceba também as diversas áreas geográficas, com grandes extensões, que não possuem cobertura alguma ou cobertura parcial do sinal da rede móvel:

Algumas regiões, mesmo contendo uma grande concentração de antenas, dificultam a propagação das ondas eletromagnéticas, utilizadas pelas antenas de telefonia móvel, devido a quantidade de morros, edifícios, lagos, árvores, etc.

Dentro desse contexto, quando o usuário utilizar o aplicativo em seu dispositivo móvel e não houver comunicação com os servidores devido a problemas de infraestrutura na rede da operadora, o aplicativo irá apresentar uma série de falhas se elas não tiverem sido tratadas pela equipe de desenvolvimento e também não identificadas pela equipe de qualidade e testes de software.

No ano passado, tive a oportunidade de acompanhar um jogo de futebol no estádio do meu time do coração. Minha ansiedade me fez chegar no estádio uma hora e meia antes da partida começar. Assim que me acomodei, procurei logo tirar uma selfie e publicar nas redes sociais. Haviam cerca de 15 mil pessoas até então e essa tarefa, simples, parecia algo impossível de ser realizada. Ao abrir o aplicativo, a tela de “loading” permaneceu na tela por cerca de 30 segundos. No entanto, depois de muito sacrifício, consegui publicar a foto. Como Engenheiro, já logo percebi que a latência estava alta devido à grande concentração de pessoas e seus dispositivos acampados em uma mesma estação rádio base (ERB) – antena de telefonia móvel.

Havia cerca de 40 mil pessoas no estádio quando a partida iniciou. Enquanto isso, um grande amigo que estava ao meu lado tentava publicar a sua selfie nas redes sociais enquanto seu dispositivo tinha 100% de sinal 4G. O aplicativo começou a apresentar diversos tipos de comportamentos “estranhos”. Ao abrir o aplicativo, por exemplo, o ícone de “loading” permanecia na tela por minutos. No entanto, ao tocar em qualquer parte da tela, uma imagem branca era apresentada com absolutamente nenhuma informação. Além disso, nesse momento, o aplicativo deixou seu dispositivo muito lento, praticamente travando. O primeiro comentário dele foi: “- Esse aplicativo ficou uma porcaria depois da última atualização.”

Ainda que o seu sinal 4G estivesse em 100%, era evidente que não havia comunicação entre o aplicativo e seus servidores, causados por problemas na infraestrutura da operadora. Havia muita perda de pacotes devido à grande quantidade de pessoas conectadas na mesma ERB, dentro e fora do estádio, e consequentemente o aplicativo não funcionava como esperado, parecia que haviam processos do aplicativo em looping.

No entanto, a equipe de desenvolvimento deveria ter tratado esses problemas mostrando uma mensagem de alerta para o usuário depois de “x” segundos sem resposta (timeout), salvando o conteúdo localmente e sincronizando quando houvesse comunicação com os servidores, realizando um ping antes da chamada de um serviço, verificando a intensidade do sinal antes de realizar uma transação, realizando um rollback na base de dados se algo der errado, e assim por diante.

Em uma outra ocasião, enquanto o usuário se deslocava em vias públicas utilizando um determinado aplicativo, o dispositivo móvel migrou de forma automática para uma outra ERB, mantendo a sessão do aplicativo aberta na ERB anterior. Isso aconteceu devido a troca do endereço lógico do dispositivo durante o processo de handover, gerenciado pelos servidores da operadora de telefonia móvel. Os usuários simplesmente tinham que aguardar cerca de 20 minutos até que a sessão, presa na ERB anterior, fosse liberada novamente. Sempre que o usuário fazia uma requisição no aplicativo, uma mensagem de erro era apresentada: “já existe uma sessão aberta para esse usuário.” Acredite, isso fazia parte da regra de negócio da organização para evitar duas conexões da mesma credencial ativas ao mesmo tempo. No entanto, isso não havia sido implementado pelos desenvolvedores da maneira correta.

Os Testes de Campo

Esses problemas poderiam ser reduzidos ou mesmo evitados através da aplicação de atividades de testes em campo. Os testes de campo, para aplicativos mobile, devem ser realizados para representar os cenários reais e a experiência dos usuários em seus ambientes. Eles são necessários para identificar a capacidade do aplicativo em manter e gerenciar a comunicação e a sessão de dados ou voz com os seus servidores com base em diversos cenários.

O foco das atividades é a avaliação do comportamento do aplicativo durante a interação do dispositivo móvel com as ERBs, frente aos cenários enfrentados pelos usuários em vias públicas e privadas como interferência na transmissão, áreas sem coberturas de rede da operadora de telefonia móvel, trocas de tecnologias de telecomunicações, trocas de antenas e frequências, etc. durante a utilização do aplicativo.

Os trechos a serem percorridos devem ser previamente mapeados em locais estratégicos, com a utilização e auxílio de ferramentas específicas, com o objetivo de identificar os cenários supracitados com base nas atividades de testes em campo a serem executadas.

Os casos de testes a serem executados também devem fazer parte da estratégia de testes em campo. Geralmente, os casos de testes para validar os fluxos, regras de negócios, funcionalidades, requisitos, etc, principais, mais críticos e mais utilizados pelos usuários são selecionados.

As seguintes atividades são alguns exemplos típicos dos testes realizados em campo para validar/testar o comportamento do aplicativo mobile, durante a execução dos casos de testes selecionados, quando o dispositivo móvel:

• Migrar de forma automática entre as tecnologias 2G/3G, 3G/2G, 3G/4G e 4G/3G (Testes de Interoperabilidade IRAT (Inter Radio Access Technology);
• Migrar de forma automática entre frequências da antena, mantendo tecnologia de transmissão de dados 2G, 3G ou 4G (Teste de Hard Handover);
• Migrar de forma automática entre as várias células de rádio base ou setores de uma mesma ERB, mantendo a tecnologia de transmissão de dados 2G, 3G ou 4G (Teste de Handover);
• Migrar de uma conexão de dados 2G, 3G ou 4G da operadora de telefonia móvel para uma conexão WIFI, de forma automática, com a utilização de ponto de acesso disponibilizado pelas operadoras em vias públicas (Teste de EAP SIM – Enhanced Access Point Subscriber Identity Module).
• Estar em ambientes de baixo sinal ou sinal nulo da operadora (Teste com Sinal Atenuado ou Nulo da Operadora – áreas de sombra);

Existem ainda outras atividades de testes em campo, que, apesar de serem realizadas de forma estática, são complementares as atividades supracitadas, como o testes de Fallbackque se resume na avaliação do comportamento do aplicativo quando o dispositivo móvel estiver conectado à rede de dados 4G e receber uma ligação, forçando o chaveamento automático para a tecnologia 3G em busca da continuidade da conexão de dados para manter a sessão do aplicativo ativa, entre outras atividades como os testes de compatibilidade de rede, testes de access point local e migração para a rede da operadora e vice-versa, etc.

Para concluir, gostaria de ressaltar a importância dos testes em campo para validação de aplicativos mobile. O objetivo, conforme já descrito nesse artigo, é encontrar e tratar as falhas do aplicativo causados pela intermitência das redes de telefonia móvel e que são encontradas pelos usuários finais.

Ainda que os testes tradicionais manuais e automatizados, executados em laboratórios, sejam imperativos para validação das regras de negócio, funcionalidades, requisitos e fluxos do aplicativo em diversos dispositivos móveis, a maior quantidade de falhas não tratadas pela equipe de desenvolvimento será encontrada durante a execução das atividades de testes em campo. Isso devido à proximidade do ambiente caótico utilizado pelos usuários.

 Referências

[1] KARNACKI, C.; OBSTLER, R. Keynote Conference 2016. jan, 2017. Disponível em: <https://pt.slideshare.net/keynote_systems/mobile-app-testing-best-practices>. Acesso em: 09 dezembro 2017.

[2] RODRIGUES, Eduardo. O sistema funciona no ambiente de desenvolvimento, mas depois de publicado os usuários começam a achar falhas. Isso é familiar para você?. Linkedin, São Paulo, jan, 2018. Disponível em: <https://www.linkedin.com/pulse/o-sistema-funciona-ambiente-de-desenvolvimento-mas-os-eduardo/>. Acesso em: 06 janeiro 2018.

[3] ABRINTEL. Projeto quer mudar licença para instalação de Antenas em SP. Disponível em: <http://www.abrintel.org.br/imprensa/telesintese-donas-de-torres-pretendem-investir-ate-r-12-bi-no-pais-este-ano/>. Acesso em 05 janeiro 2018.

[4] TIM. Mapa de cobertura TIM. Disponível em: <http://www.tim.com.br/sp/para-voce/cobertura-e-roaming/mapa-de-cobertura>. Acesso em: 06 janeiro 2018.

Por: Eduardo Rodrigues