Mobile Testing Automation

Devido ao acelerado crescimento no número de usuários de dispositivos móveis, o desenvolvimento de aplicativos para tais plataformas tem tomado conta do mercado. Porém, ainda que os sistemas tenham mudado de interface, os mesmos ainda precisam ser testados.

Na Atomic, o processo de automação de teste de aplicações mobile utiliza um framework dinâmico e intuitivo, que permite escalabilidade e reutilização. Neste artigo serão apresentados conceitos e fundamentos sobre automação de testes em ambiente mobile.

Tipos de teste

Quando se trata de teste aplicações mobile, é importante diferenciar o objeto do teste, que podem ser:

Aplicativos Nativos: instalados e executados em uma única plataforma (Android ou IOS, por exemplo);
Web apps: Sistemas acessados através de mobile browser;
Aplicativos híbridos: uma combinação de aplicativos nativos e web apps.

Framework

Ao testar mobile apps, diferentes ferramentas e arquiteturas são possíveis.

A compatibilidade e performance de um aplicativo está diretamente ligada à versão do SO em que ele está instalado. Isso faz com que diversos aparelhos e versões sejam testadas para garantir sua usabilidade.

A fim de garantir a abrangência necessária dos testes, um pool de dispositivos deve ser selecionado. No mercado, há diversas soluções que vendem devices as a service, como a AWS Device Farm, que permitem a execução dos testes automáticos sob demanda, e disponibilizam diversas versões de aparelhos e Sistemas Operacionais.

Scripting

A automação se dá através de criação de scripts que simulam a interação humana com o aplicativo objeto do teste. Tais códigos podem ser gerados através de diversas ferramentas, como o Appium.

O Appium é uma ferramenta open source cross-platform, disponível para sistemas Android, iOS e Windows, que utiliza um método de reconhecimento de objetos através de screenshot. A partir deste mapeamento, é possível interagir com os objetos de diversas formas, a fim de criar um script de teste.

Assim como em aplicações desktop, os testes podem ser seccionados em componentes.

Um componente é responsável por uma tela ou uma ação, e deve ser criado sempre visando o reaproveitamento, o que facilita muito na manutenção dos scripts. A maioria dos apps, por exemplo, tem uma tela de Login: o ideal é criar apenas um componente que ficará responsável por essa tela, que será chamado nos cenários de teste onde haja login.

O mesmo se aplica por exemplo para a emissão de uma passagem, a consulta de saldo ou até mesmo a alteração de dados cadastrais. Todos os componentes podem ser utilizados em diversos cenário diferentes.

Data Management

Tendo definido a ferramenta responsável pela criação dos scripts de teste, e os dispositivos que serão utilizados na execução, resta definir como serão geridos os dados de teste (massa de dados).

Pode-se usar planilha excel, arquivos CSV ou até mesmo um banco de dados relacional.

A Atomic dispõe de um framework de Data Driven Testing robusto, denominado Proton Framework, que além de servir como repositório, gera relatórios e até mesmo faz a orquestração dos testes.