T-REX PRADA III: Uma heurística mnemotécnica para testes em dispositivos móveis

RESUMO
O presente artigo tem como objetivo de criar a discussão de um sistema pragmático e de fácil recordação que possa ser usufruído durante os mais diferentes níveis de teste na análise e no desenvolvimento de testes de software em aplicativos desenvolvidos nativamente ou de forma híbrida para dispositivos móveis. Neste âmbito, fora idealizado uma heurística baseada em mnemônica, tratado como “T-REX PRADA III”, para a realização dos possíveis testes estabelecidos. Esta heurística também inspirou-se das citações de heurísticas citadas por Janet Gregory e Lisa Crispin em seus livros, e pela heurística T-PAIN desenvolvida por Rafael Bandeira.

Palavras-Chave: Heurística, testes, mobile, QA, mnemônica, Android, iOS, qualidade, tomada de decisões, estratégia, dispositivos móveis.

1 INTRODUÇÃO

Uma heurística é uma palavra do grego que significa “descobrir”. É uma abordagem para a resolução de problemas que leva em conta a experiência pessoal. As heurísticas fornecem estratégias para examinar um número limitado de sinais e/ou escolhas alternativas na tomada de decisão. As heurísticas diminuem o trabalho de recuperação e armazenamento de informações na memória; simplifica o processo de tomada de decisão, reduzindo a quantidade de informações integradas necessárias para fazer a escolha ou julgar. (Fonte: Adaptado de Heuristics and biases: The science of decision-making).

Os resultados das avaliações heurísticas podem ser usados para identificar problemas de usabilidade e para medir a usabilidade. (Fonte: Adaptado de Keevil B. Measuring the usability index of your Web site. Proceedings of the 16th annual international conference on Computer documentation — SIGDOC ’98, 1998).

De acordo com a teoria do fluxo, ter um objetivo claro em mente é o núcleo de uma experiência agradável. (Fonte: Adaptado de Csikszentmihalyi M., Flow: The psychology of Optimal Experience, Harper Perennial, MA, 2005).

2 DISCUSSÃO

Sabe-se da importância da qualidade na área de desenvolvimento de softwares, atividade esta que se deve iniciar o quanto antes, como por exemplo na análise de requisitos. Porém, para realizar testes em um software, o testador não deve começar a testar apenas por meio exploratório ou apenas realizar testes baseado em sua experiência, deve-se usufruir também de estratégias e métricas de testes para a resolução de um determinado problema.

Com isto, nasce-se a heurística de testes, uma análise de objetivos que auxilia o testador para que ele possa obter um caminho previamente mapeado para o ajudar na realização dos seus testes.

Uma heurística de testes pode ser representada por diferentes abordagens, citarei aqui três meios diferentes de se utilizar uma heurística:

Primeiro, uma heurística por meio de checklists, onde são descritos os cenários detalhadamente, o passo-a-passo que o testador deve seguir ao executar um teste.

Segundo, uma heurística por meio de mapas mentais, onde as informações são organizadas de modo visual, onde as diferentes abordagens são representadas por diferentes ramos, apresentando todos os tópicos do objeto de análise.

E terceiro, uma heurística por meio de mnemônica, cujo é uma técnica para aperfeiçoar a memória, criando-se, por exemplo, um conjunto de palavras, arranjos ou elementos que facilite o usuário à memorização. Portanto, uma técnica que pode ser útil fazendo com que o testador recorde quais são os elementos mais importantes a serem testados em sua suíte de testes.

Obtendo-se o conceito de heurística em mente, e sabendo a necessidade de cada vez mais estarmos atuando com aplicações mobile, venho a propor uma heurística baseada em mnemônica para que se possa utilizar como base quando o testador for realizar testes em uma aplicação mobile.

Sendo assim, apresento-vos a mnemônica “T-REX PRADA III” — onde cada letra desta mnemônica representará uma abordagem de testes que deverá ser refletida quando for realizado os testes em uma aplicação mobile.

Figura 01: Representação gráfica da mnemônica “T-REX PRADA III” para facilitamento de fixação.

As abordagens que serão representadas por meio dessa mnemônica são:

T de Tema escuro;
R de Rotação do dispositivo móvel;
E de Experiência do usuário;
X de Xiaomi;
P de Permissões;
R de Responsividade;
A de Amplificação;
D de Diferentes modelos e versões;
A de Atualização do aplicativo atual;
I de Interrupções;
I de Internet;
I de Interceptadores.

2.1 T de Tema escuro

Dentro dos ajustes, nas configurações do seu dispositivo móvel, existe a opção de modificar a aparência padrão da sua tela e brilho de “claro” para “escuro”. Ao usufruir desta configuração, o tema geral dos comportamentos nativos presentes em seu dispositivo móvel se converte para o modo escuro (no que chamamos de “dark mode”), fazendo que os elementos gráficos que previamente estavam em um modo claro e com cores vivas, passam a ficar e em um modo escuro e com cores frias, com o intuito de reduzir a exposição à luz azul e ao cansaço visual dos usuários que os utilizem.

Com isto, caso a aplicação que o testador esteja testando não tenha um bom padrão de design que se adeque ao “dark mode”, e que a aplicação não obtenha bloqueio para o mesmo, existe a grande possibilidade de que um usuário que esteja com este tema possa estar utilizando o aplicativo de uma maneira que não fora planejada previamente, como componentes que antes respeitavam a teoria das cores de Goethe, passam a ficar fora de padrão com o modo escuro, como uma label que no modo claro possui a cor preta, passa a ficar ofuscada pela tela de fundo preta do modo escuro, ou alguma animação em CSS que não pode ser apresentada.

Estas ou outras propriedades podem decair consideravelmente a manipulação que o usuário tem de uma determinada interface gráfica, e, por conseguinte, a sua experiência.

2.2 R de Rotação do dispositivo móvel

Existem duas maneiras de visualizar as informações que estejam em seu dispositivo móvel, podendo ser o modo retrato ou o modo paisagem. Geralmente, ao se desenvolver um aplicativo, é concebido a ideia de estar utilizando apenas uma das maneiras de visualização (a menos que a aplicação em si tenha algum fluxo onde a função é abrir a câmera do seu dispositivo, ou abrir algum documento em específico que precisa ser visualizada em modo paisagem).

Por este motivo, é necessário testar, se, ao alternar-se entre os modos, podem ocorrer erros no layout da sua aplicação, como por exemplo um toast que pode não ficar responsivo no modo paisagem.

2.3 E de Experiência do usuário

Basicamente a experiência do usuário analisa “o como” que o usuário manipula a aplicação, podendo abranger todas as interações que o usuário pode realizar com ele. Dentre estas interações, podemos citar a atratividade que o aplicativo demonstra para o usuário, perante a outras aplicações, se todas as funcionalidades daquele aplicativo são intuitivas ao usuário, ou se o aplicativo é acessível para pessoas que possuem alguma dificuldade motora e/ou visual.

Ao mesmo tempo que o aplicativo tem que ser inovador e criativo, também não pode ser algo muito adverso do que os demais aplicativos similares do mercado de trabalho.

Portanto, a análise do testador pode resgatar todas essas características e averiguar se o aplicativo testado se encontra em bons padrões de UI/UX, para assim, obter bons critérios de perceptibilidade, operabilidade e compreensibilidade.

2.4 X de Xiaomi

Esta seção é específica para dispositivos móveis que estejam operando o Android SO. No caso em específico, estaremos nos referindo aos da marca Xiaomi. O que ocorre é que a Xiaomi utiliza um ROM próprio que customiza o Android SO, criando um firmware customizado, denominado de MIUI. Esta ROM modificada pode muitas vezes apresentar comportamentos adversos e inesperados na aplicação que você está testando, comportamentos estes que muitas vezes podem passar despercebidos ao testar um outro dispositivo móvel com um Android SO não-modificado.

Uma destas especificidades de alguns dispositivos Xiaomi é o de forçar o dark mode em uma aplicação mobile (por mais que o dark mode seja bloqueado para o Android SO), fazendo com que a interface fique numa propriedade que não fora estudado anteriormente pelos designers.

Ou quando o dispositivo não reconhece a biometria facial ao entrar em uma aplicação (a não ser que este esteja programado no código da aplicação que o parâmetro de autenticação seja fraco ao invés de forte), como é um caso específico que ocorre nos Xiaomi Redmi Note 8 Pro.

Vale ressaltar que não é apenas o Xiaomi que pode realizar alterações no Android SO, alguns outros exemplos são: TouchWiz da Samsung, EMUI da Huawei e Oxygem da OnePlus.

2.5 P de Permissões

Dentro de ajustes, nas configurações da aplicação a ser testado em específico, o testador tem a possibilidade de dar acesso a diferentes permissões, dentro eles podendo ser: localização, câmera, biometria, notificações, contatos, microfones, galeria, entre outros.

É de responsabilidade do testador verificar qual vai ser o comportamento da aplicação quando é concedido estas permissões, e quando é retirando-os durante a utilização. Por exemplo, o que deverá ser demonstrado ao usuário quando é necessário que ele ative alguma permissão do dispositivo para que ele possa continuar utilizado a aplicação.

Um outro fator que também é importante de ser testado é como o aplicativo se comporta quando o seu armazenamento e cachê são limpos.

2.6 R de Responsividade

No quesito de testes mobile, a responsividade trata-se de como é a adaptação de uma tela de uma aplicação em relação a diferentes dispositivos móveis com tamanhos diversos de tela.

Para que a responsividade seja adequada, a tela, o sistema ou o componente a ser analisado tem que estar completamente funcional, independentemente do tamanho de tela do dispositivo móvel que esteja sendo utilizado para testar.

Como não é viável obter todos os tamanhos de telas presentes hoje no mercado, é recomendado pelo menos testar a aplicação em um dispositivo, emulador ou simulador que obtém o menor tamanho de tela, e o que obtém o maior tamanho de tela, eliminando assim os possíveis erros de layout.

2.7 A de Amplificação

A amplificação pode ser considerada como uma extensão da responsividade, porém, gostaria de categorizar aqui como sendo uma representação diferente da mnemônica criada, pois ela pode ser utilizada em conjunto com a responsividade para testes.

A amplificação pode ser ajustada dentro de ajustes, nas configurações de tela, na subcategoria de zoom da tela (no caso dos dispositivos iOS), ou dentro das melhorias de visibilidade, na subcategoria de zoom da tela (no caso dos dispositivos Android). A amplificação faz com que todo o conteúdo apresentado seja ampliado, facilitando a experiência para usuários que podem possuir uma deficiência visual.

Além de ampliar o zoom da tela, também pode ser necessário que o usuário final aumente o tamanho das letras na tela, podendo fazer com que a junção dessas ampliações aumente as chances de quebra de layout da aplicação. Porém essa junção de fatores pode não ser um teste viável, visto que a porcentagem de usuários que vão usufruir dessas duas modificações é mínima.

Contudo, resta a expertise do testador verificar se os testes são viáveis ou não na sua determinada aplicação.

2.8 D de Diferentes modelos e versões

Independentemente se você estiver testando aplicativos nativos ou híbridos, cada modelo de dispositivo e cada versão de dispositivo pode apresentar diferenças em seu funcionamento, podendo ser ou não de interface. Cada dispositivo tem a sua particularidade, e a cada versão do sistema operacional pode ser atualizado e/ou ser depreciado alguma funcionalidade em sua biblioteca interna, como por exemplo a versão 12 do iOS que não consegue ler arquivos .svg nativamente e demonstrar na tela.

Como não é viável obter todos os diferentes modelos de dispositivos móveis e versões dos SO que tem hoje no mercado, é recomendado pelo menos que o testador realize os testes nos dispositivos e versões que mais são utilizados na aplicação, ou no caso de uma aplicação nova, os dispositivos e versões que mais são utilizados no mercado.

2.9 A de Atualização do aplicativo atual

Todas as aplicações passam por atualizações, e em algum momento a aplicação testada vai ter que ser publicada para o público, seja na Google Play Store (para aplicativos Android), ou na AppStore (para aplicativos iOS).

Portanto, considerando que há uma versão nova do aplicativo atual, é necessário realizar-se os testes de adequação. Durante esta atualização, primeiro é necessário realizar testes de confirmação para averiguar se os novos recursos propostos na atualização estão sendo implementadas de forma correta, e por conseguinte, é necessário realizar testes regressivos para verificar se estes recursos que foram implementados não afetaram nenhum outro funcionamento dentro do aplicativo.

Como há uma nova atualização para o aplicativo, também deve-se verificar como que o aplicativo desatualizado vai se comportar com esta nova atualização (pode ser que a API altere algum endpoint que vai afetar diretamente as versões desatualizadas do aplicativo), e como que pode ser apresentado a mensagem de que há uma nova atualização do aplicativo para o usuário.

O testador também pode ficar atento às informações que estão contidas sobre a atualização fora do aplicativo, se as descrições estão corretas nas suas respectivas lojas, por exemplo.

2.10 I de Interrupções

Pode-se ter várias interrupções no momento no qual for testado um aplicativo. Por este motivo, deve-se também verificar qual será o seu comportamento quando for exercido a estas interrupções.

Por exemplo, deve-se indagar e verificar qual será o comportamento do aplicativo no momento que o usuário estiver recebendo uma ligação, ou quando o usuário receber uma notificação de prioridade 0, ou quando o usuário deixar o aplicativo em segundo plano e tenta retomar a atividade, basicamente qualquer motivo no qual o aplicativo fique sobreposto.

Todas estas sobreposições podem fazer com que em algum momento o aplicativo em questão possa perder a sua sessão, expirando-se algum token de acesso, por exemplo, fazendo com que o aplicativo não fique funcional, necessitando que ele seja reinicializado.

2.11 I de Internet

Outra questão a ser verificada é sobre a estabilidade do aplicativo no momento que ele é colocado em uma conexão com banda menor, como por exemplo uma conexão 2G ou 3G.

Como que o aplicativo deve reagir com timeouts, e se é apresentado alguma mensagem de feedback para o usuário verificar a sua conexão.

Também pode ser verificado como o aplicativo reage no momento que o usuário ativa o modo avião, um recurso que desliga os sistemas de telefonia celular, Wi-Fi, NFC, Bluetooth e GPS. Ou até mesmo verificar como se comporta quando há alguma dificuldade de processamento do servidor interno (HTTP error 5xx).

2.12 I de Interceptadores

E por último, mas não menos importante, ao testar uma aplicação mobile pode-se utilizar softwares interceptadores para verificar como que a informação está se deslocando do front-end e chegando no back-end.

Com isto, podemos analisar, por exemplo, se o front está enviando as informações de uma forma que a API possa entender, se está enviando alguma informação sensível de modo não-criptografada, se o cabeçalho está com todas as informações, se o corpo da requisição está passando todos os atributos e valores corretamente, ou até diferenciar se uma determinada mensagem advém da API ou não.

Para que o testador ative os interceptadores, é necessário permitir que estes softwares possam visualizar os tráfegos em protocolos HTTP ou HTTPS entre o seu dispositivo móvel e a rede que o testador está conectado, configurando um proxy manual para o mesmo (vale ressaltar que, se o testador estiver utilizando um outro dispositivo para o interceptador, o dispositivo móvel e o dispositivo que está configurado o interceptador tem que estar na mesma conexão de rede para que estas operações funcionem). Alguns exemplos de softwares que fazem essa interceptação são: Burp Suite, Flipper, Charles Debugging Proxy, Fiddler, Proxyman, Bagel (somente para iOS), HTTP Canary (somente para Android), entre outros. Em alguns interceptadores, também é necessário configurar um certificado no dispositivo móvel para que o interceptador possa fazer essa comunicação.

Ressalto também que esta interceptação só é possível para aplicações nativas, não podendo ser utilizadas para aplicações que obtenha algum código escrito em linguagens híbridas (estes frameworks são construídos com baixo nível de TLS e HTTP, não podendo ser interceptado a não ser que faça alguma engenharia reversa para tal), ou caso o aplicativo a ser testado tenha alguma ofuscação ou SSL Pinning (checagem adicional de certificados intermediários), a interceptação também não funcionará.

3 CONCLUSÃO

Fora observado que existem vários meios que podem auxiliar o testador a criar uma estratégia de testes, sendo uma delas a heurística. Por mais absurdo que seja a mnemônica criada (como visto aqui, uma ligação mnemônica por exagero: “T-REX PRADA III”), é necessário que a mnemônica seja de fácil recordação e impactante para que ela seja fixada na memória do testador.

Há também outros critérios que se deve utilizar para testar aplicações mobile, além das especificadas nesta mnemônica, como por exemplo: como que o aplicativo reage quando é utilizado o modo de economia de energia; como que a funcionalidade do aplicativo se adequa quando há pouco espaço em seu armazenamento interno; ou até mesmo quando o aplicativo a ser testado é armazenado em uma memória externa como um cartão SD.

Em suma, na prática é impossível realizar-se análises de abordagem de testes com cobertura máxima, abrangendo todas as versões de sistemas operacionais, dispositivos, fabricantes, operadoras ou tipos de rede que existem. Por este motivo, esta heurística pode ser um recurso de grande valia na execução dos seus principais testes, além de ser um objeto coadjuvante no aperfeiçoamento da sua carreira.