3/5/2026
Regressão Automatizada: o que considerar antes de partir para essa estratégia


Júlio Viegas
Co-founder
8/5/2026
Fora o tamanho da tela, há vários outros aspectos que influenciam no planejamento e no alcance de um aplicativo mobile. Ao falar em problemas de compatibilidade ou adaptação em apps, a primeira coisa que pensamos é em quebras de layout ou na visualização de informações. Apesar de ser um problema bastante relevante, existe uma outra questão tão grande quanto: a adaptação do aplicativo aos diferentes hardwares.O caso do AndroidCom 24 mil modelos diferentes, o Android é uma plataforma bastante fragmentada. Isto se dá pelo fato do Android ser um sistema operacional mobile com código aberto, que é adotado por uma série de fabricantes diferentes que fazem uma parceria com o Google - elas podem personalizá-lo e embuti-lo em várias combinações de hardware diferentes.
Além de serem fabricados por empresas diferentes, os smartphones Android têm muita diferença internamente — às vezes até no mesmo celular. O Galaxy S7, último smartphone topo-de-linha da Samsung, tem duas versões: uma com processador da própria Samsung, um Exynos 8890 e outra com processador da Qualcomm, um Snapdragon 820. No Brasil, apenas a versão com Exynos é comercializada.

Ainda relacionado a processadores, outro problema, que costuma acontecer em aplicativos que exigem mais do sistema, é a diferença entre ARM e x86, duas das principais arquiteturas para celular — responsável por processar e transformar dados. A maioria dos smartphones hoje é baseada em ARM, usada pela Qualcomm, Samsung e MediaTek (todas são fabriacantes de processadores). No entanto, muitos smartphones da Asus no Brasil, como o Zenfone 2, ainda usam processador da Intel, baseado em x86.A diferença de arquitetura é decisiva na hora de aumentar o alcance de um aplicativo. O recém-lançado Pokémon Go, por exemplo, era compatível apenas com processadores ARM, o que deixou vários usuários chateados. Logo depois, a Niantic, desenvolvedora do jogo, adaptou o código e Pokémon Go passou a funcionar em smartphones com x86.
Para desenvolvedores menores e projetos mais localizados, a compatibilidade pode virar uma grande dor de cabeça.
Para ter uma ideia da dimensão do problema, conversei com Matheus Cassiano, desenvolvedor de Android na iOasys, que também aponta a câmera como vilã. “A câmera costuma dar bastante problemas. As APIs, códigos-base para programação de um aplicativo, variam de acordo com as fabricantes e já tivemos bastante problemas com isso.”, disse.“O Android tem algumas APIs que te dão controle sobre o sensor, mas costumam falhar em dispositivos específicos. Acabamos com crashes em alguns dispositivos por conta disso. Fora a câmera, não me lembro de ter trabalhado com outras peças de hardware que deram trabalho”, disse o desenvolvedor.

Matheus deu duas dicas que podem ser úteis. Eis uma dica para display e outra para solucionar o pesadelo da câmera:
Agora você deve estar pensando: nossa, que ruim desenvolver para Android. Vou só focar no iPhone, que não tem esses problemas. Não é bem assim...
Apesar de ter dispositivos unificados, com poucos tamanhos de tela, os desenvolvedores para iOS também têm desafios na hora de desenhar e adaptar os aplicativos. Aproveitando o gancho da iOasys, falei com João Pedro Melo, o desenvolvedor de iOS da empresa, que me contou que o maior vilão se chama iPhone 4s. E também é por conta do hardware.No lançamento, o iPhone 4s ainda tinha 512 MB de RAM, metade do seu sucessor, o iPhone 5, que tem 1 GB. "É bem comum você fazer um app que está funcionando muito bem no iPhone 5 (que já está começando a mostrar os sinais da idade) mas quando chega no 4s tudo começa a dar errado. Isso fica mais visível quando você lida com coisas que podem consumir muita memória, como fotos. Já presenciei casos de que simplesmente abrir a câmera num app, no 4s, fazia ele dar crash por falta de memória", explica João.

A proporção da tela também torna o 4s meio odiado pelos desenvolvedores, já que o suporte é praticamente obrigatório por ele ser bem popular no Brasil. Todos os iPhones depois dele, 5, 5s, 6 e 6s, têm proporção 16:9. “Muitas vezes na verdade não é preciso fazer nada, você faz o app pensando num iPhone 5 e ele “magicamente” funciona até no 6 Plus sem nenhum problema de layout”, diz o desenvolvedor.“Já o 4s é diferente, pois ele tem menos espaço vertical. Muitas vezes, isso te obriga a pensar em layouts levemente diferentes especialmente para o 4s. Felizmente, ele está quase no final da sua vida, tanto que não vai receber o iOS 10. No entanto, a Apple recomenda que seu aplicativo tenha suporte a pelo menos à versão atual e anterior do iOS, então os desafios com ele ainda vão continuar por algum tempo”, completa.
Outro ponto, segundo João, é suportar versões anteriores do iOS. Em uma versão nova do sistema, recursos interessantes não aparecem só para os usuários: eles também facilitam a vida do desenvolvedor. Mas a adoção pelo usuário normalmente é baixa porque nem todo mundo atualiza para a nova versão.“O iOS 9 teve novidades legais, e todos os aparelhos que rodavam iOS 8 poderiam fazer upgrade para o 9. Mas, nem todos fizeram, talvez por falta de espaço. Muita gente ainda não sabe que você pode atualizar o sistema pelo iTunes mesmo com o armazenamento lotado. Isso fez com que nós não pudéssemos usar algumas novidades do iOS 9”, explica o desenvolvedor.

Por fim, na fabricação dos aparelhos, existe praticamente uma linha que divide os mais novos, que suportam todos os recursos, e os mais antigos, que por vezes ficam para trás. É a própria Apple quem faz o processador dos iPhones e, a partir do iPhone 5s, ela passou a usar a arquitetura de 64-bits, em vez de 32-bits, usada antigamente.Com isso, APIs como a do “content blocker”, que permite a criação de bloqueadores de anúncios, ficaram restritas a versões mais novas dos aparelhos, deixando de fora os modelos 4s, 5 e 5c.Todos esses problemas podem vir de surpresa para gestores de projeto e até para os próprios desenvolvedores. Recomendo que você trace bem o escopo de seu aplicativo para não ter imprevistos no final.

Júlio Viegas
Co-founder
Cofundador da Sofist. Empreendedor há mais 10 anos na área de software, formado em Ciência da Computação pela Unicamp.
Aspecto
Outsourcing
tradicional
Crowd-testing
One Day Testing
Contratação ágil, execução e entrega de resultados
Ruim
Médio
Ótimo
Preserva a confidencialidade dos seus dados e software
Ótimo
Ruim
Ótimo
Teste as habilidades da equipe
Ótimo
Imprevisível
Ótimo
Controle sobre a execução do teste
Ótimo
Ruim
Ótimo
Comunicação entre o cliente e a equipe de teste
Ótimo
Ruim
Ótimo
Elasticidade para lidar com oscilações de demandas de testes
Ruim
Ótimo
Ótimo
Custos de aquisição e manutenção
Ruim
Médio
Ótimo