A equipe testa o aplicativo durante todo o sprint, lança a versão — e uma semana depois, as reclamações começam a chegar ao suporte: “o preço na minha cidade é diferente”, “o push não chegou”, “não consigo pagar com cartão”. A razão é quase sempre a mesma: todos os testes foram realizados a partir de um único IP corporativo, enquanto os usuários reais acessam de outras regiões, redes e operadoras. Neste artigo, analisaremos 7 cenários específicos de QA que são fisicamente impossíveis de testar sem mudar o endereço IP, e mostraremos como configurar a infraestrutura de teste com proxy.
Por que o IP de escritório é uma zona cega para QA
A maioria dos aplicativos móveis hoje toma decisões com base no endereço IP: determina o país do usuário, o idioma da interface, a moeda, os métodos de pagamento disponíveis, o conjunto de recursos e até mesmo o preço da assinatura. Quando todo o departamento de QA testa de um único escritório com um IP estático de um data center ou rede corporativa, o aplicativo sempre recebe a mesma resposta do backend — como se todos os testadores estivessem em um único ponto do mundo.
Como resultado, bugs que dependem da geolocalização, hora do fuso horário, operadora de telefonia ou tipo de conexão simplesmente não se reproduzem no ambiente de teste. Eles aparecem apenas na produção — quando um usuário do Cazaquistão vê preços em rublos, um usuário alemão não recebe push devido ao bloqueio do GCM em sua rede, e um cliente indonésio não consegue pagar com cartão porque o provedor de pagamento para sua região não está conectado. Corrigir um bug desse tipo após o lançamento custa muito mais do que capturá-lo na fase de QA.
A solução é emular a verdadeira diversidade geográfica e de rede dos usuários antes do lançamento. Para isso, os engenheiros de QA estão cada vez mais utilizando servidores proxy: eles permitem "mover" o dispositivo de teste ou emulador para qualquer país, cidade ou até mesmo operadora de telefonia sem a necessidade de ir fisicamente até lá ou comprar dezenas de SIM cards.
Cenário 1: Geoconteúdo e preços regionais
A maioria dos aplicativos com assinaturas (streaming, fitness, educação) mostra preços diferentes em diferentes países — isso é chamado de geopricing. Se o QA verifica a assinatura apenas com um IP local, não é possível garantir que o preço para um usuário da Turquia, Brasil ou Índia seja exibido corretamente, na moeda certa e com o arredondamento correto.
O mesmo problema ocorre com catálogos de conteúdo: a biblioteca de filmes, produtos ou promoções é frequentemente regional. É necessário "aparecer" fisicamente no país desejado para ver a mesma tela que um usuário real vê. Para essas verificações, é conveniente usar proxies residenciais — eles fornecem IPs de usuários domésticos reais de um país específico, e o backend do aplicativo percebe a solicitação como tráfego orgânico normal, e não como uma solicitação de um data center.
Checagem prática: executamos o cenário de assinatura em 8-10 mercados-chave (EUA, Alemanha, Brasil, Índia, Turquia, Japão, Nigéria, Emirados Árabes Unidos), registramos capturas de tela do preço e da moeda, e comparamos com a lista de preços do produto. Isso cobre a maior parte das reclamações do tipo “por que meu preço é diferente”.
Cenário 2: Geobloqueios e restrições de acesso
Aplicativos fintech, serviços de streaming e alguns jogos bloqueiam o acesso de certos países por razões legais ou de licenciamento. O QA deve garantir não apenas que o aplicativo funcione onde deve, mas também que ele recuse o acesso corretamente (e não com um crash) onde não deve.
Um bug típico: em vez de uma tela cuidadosa "serviço indisponível em sua região", o usuário vê uma tela em branco ou um carregador infinito — porque os desenvolvedores testaram apenas o caminho feliz de um país permitido. A verificação de geobloqueios requer conexões sequenciais de várias jurisdições proibidas, o que em SIM cards reais e viagens de negócios é irrealista, mas através de proxies leva de 10 a 15 minutos por país.
Para este cenário, são adequados proxies com geolocalização precisa no nível da cidade, e não apenas do país — é importante verificar não "Alemanha como um todo", mas terras específicas, se a licença for limitada a uma região dentro do país.
Cenário 3: A/B e rollouts graduais por países
Feature flags e rollouts graduais quase sempre são configurados com base na geolocalização: um novo recurso é ativado primeiro no Canadá, depois em uma semana na Austrália, e depois em todo o lugar. Se a equipe de QA estiver fisicamente em um único país, ela não pode ver a nova versão antes de outras regiões, até que a flag chegue até ela.
Para testar um recurso antes do lançamento global, é necessário substituir a geolocalização pelo país da primeira onda de rollout. Esta é uma das tarefas mais comuns que os proxies resolvem em conjunto com navegadores anti-detect ou emuladores de dispositivos — mudamos o IP para o país desejado, reiniciamos a sessão do aplicativo, vemos o recurso antes dos outros usuários e conseguimos encontrar bugs antes que a flag chegue a 100% da audiência.
Um ponto importante: para testes A/B, é necessária uma "residência" estável do IP durante todo o ciclo de teste — a sessão não deve saltar entre países entre as solicitações, caso contrário, o backend confundirá as condições do experimento e mostrará tanto o grupo de controle quanto o grupo de teste.
Cenário 4: Localização e notificações push
O texto da notificação push, o horário de envio e até mesmo o fato da entrega muitas vezes dependem da geolocalização do dispositivo. Em alguns países, provedores de push (Firebase, APNs, gateways SMS locais) operam com atrasos ou através de rotas alternativas — e o que é perfeitamente entregue no ambiente de teste do escritório em Moscou pode não chegar ao usuário na Indonésia devido ao bloqueio de servidores de push específicos pelo provedor local de telecomunicações.
Além disso, a localização da interface muitas vezes é acionada pelo IP, e não apenas pelo idioma do sistema: um usuário com o idioma do telefone em inglês, mas IP da França, pode ver uma interface mista — cabeçalhos em francês, botões em inglês. Esses bugs são 100% invisíveis se todo o QA testar de uma única geozona.
Processo recomendado: pegamos 5-7 locais dos mercados prioritários do produto, conectamos através de proxy com o IP correspondente, mudamos o idioma do sistema no dispositivo/emulador e registramos qual texto e formato de datas/números o aplicativo mostra. Desvios entre o IP do país e o idioma do sistema são um caso obrigatório separado, que muitas vezes é esquecido.
Cenário 5: Métodos de pagamento e sistemas antifraude
O conjunto de métodos de pagamento disponíveis em um aplicativo móvel quase sempre depende do país: em uma região, o pagamento com cartão e Apple Pay está disponível, em outra — apenas carteiras locais (Mercado Pago, Boleto, UPI, QIWI), em uma terceira — pagamento através da operadora de telefonia. Se o QA não consegue se conectar do país necessário, metade dos cenários de pagamento permanece não testada até a produção, onde o custo do erro é a receita perdida e reclamações no suporte.
Uma dor separada — sistemas antifraude dos provedores de pagamento. Eles avaliam o risco da transação também com base no IP: uma solicitação com IP de data center quase certamente receberá uma recusa ou uma verificação adicional de 3D-Secure, mesmo que o cartão seja absolutamente válido. Isso distorce os resultados dos testes: o QA vê a recusa no pagamento e reporta um bug para os desenvolvedores, embora o problema não esteja no código, mas no fato de que o IP de teste parece suspeito para a pontuação antifraude.
Para cenários de pagamento, é melhor usar proxies residenciais ou proxies móveis — eles se parecem com tráfego normal de um usuário real e não acionam disparos desnecessários nos sistemas antifraude, o que proporciona uma visão mais honesta do comportamento do fluxo de pagamento.
Cenário 6: Comportamento em redes móveis de operadoras
Um aplicativo que funciona perfeitamente no Wi-Fi do escritório a 200 Mbps pode se comportar de maneira completamente diferente em uma rede móvel 3G/4G com conexão instável, proxy NAT da operadora e alta latência. Timeouts de solicitações, tentativas repetidas, degradação da qualidade de vídeo/áudio, funcionamento do modo offline — tudo isso é crítico para ser testado em condições próximas à internet móvel, e não em uma rede de escritório estável.
Uma dificuldade adicional: algumas operadoras aplicam seus próprios proxies e CGNAT, fazendo com que o servidor veja não o IP real do usuário, mas o IP compartilhado da operadora, através do qual milhares de assinantes passam ao mesmo tempo. Isso afeta a limitação de taxa e a geolocalização pelo IP — o aplicativo pode "pensar" que o usuário está em outra cidade do que realmente está.
Para reproduzir esse comportamento, são necessários proxies móveis que saem para a internet através de SIM cards reais das operadoras do país desejado — isso fornece uma imagem precisa do NAT, latências e velocidades, que não podem ser obtidas com um IP de data center comum.
Cenário 7: Limitação de taxa e proteção contra bots
Muitas APIs de backend de aplicativos móveis limitam o número de solicitações de um único IP (limitação de taxa) e usam proteção contra bots, semelhante a captcha ou análise comportamental. Se a equipe de QA executa testes automatizados de um único IP corporativo, após algum tempo o servidor começa a responder com erros 429 ou a bloquear solicitações inteiras — e os testes falham não devido a um bug no aplicativo, mas porque o backend interpretou o tráfego de teste como um ataque.
Isso é especialmente relevante para testes de carga e regressão, quando é necessário executar centenas de solicitações semelhantes em um curto período de tempo (registro, login, adição ao carrinho). Distribuir solicitações entre diferentes IPs através de um pool de proxies permite sobrecarregar a API de forma justa, sem distorcer os resultados devido à ativação da proteção antifraude.
Para esse tipo de teste automatizado em massa, muitas vezes é mais vantajoso usar proxies de data center — eles são mais rápidos e mais baratos em grandes volumes de solicitações, e a geolocalização nesse cenário não é tão crítica quanto a velocidade e a estabilidade da conexão.
Ferramentas e configuração de proxy para QA
Para QA manual em emuladores (Emulador do Android Studio, Simulador do Xcode), o proxy é configurado através das configurações de rede do emulador: você especifica o IP e a porta do servidor proxy, login e senha, se a autenticação for usada. Para dispositivos reais, configurações semelhantes estão disponíveis na conexão Wi-Fi através de “Configurações avançadas → Proxy → Manualmente”.
Para interceptar e analisar o tráfego entre o aplicativo e o backend, os engenheiros de QA usam Charles Proxy ou Proxyman — ambas as ferramentas permitem passar o tráfego do aplicativo através de um proxy externo e ver simultaneamente todas as solicitações HTTP/HTTPS, cabeçalhos de geolocalização e respostas do servidor. Isso é conveniente para diagnóstico: é imediatamente visível qual IP e qual país o backend "vê" no momento da solicitação.
Para testes automatizados através do Appium ou Espresso, o proxy é especificado nas capacidades desejadas da sessão ou através das configurações do dispositivo antes do início do conjunto de testes. Plataformas de nuvem para testes de aplicativos móveis (BrowserStack, Sauce Labs) também suportam a conexão de proxies personalizados, permitindo executar o mesmo cenário de teste automatizado de diferentes países sem dispositivos físicos em cada ponto do mundo.
Se a equipe tiver uma versão web do aplicativo ou precisar testar várias contas com diferentes geolocalizações simultaneamente, é conveniente usar navegadores anti-detect (Dolphin Anty, AdsPower, Multilogin) — cada perfil é vinculado a um proxy separado, e o engenheiro de QA pode manter abertas de 5 a 10 sessões de diferentes países ao mesmo tempo, sem confusão em cookies e cache.
Qual tipo de proxy escolher para cada cenário
| Cenário de QA | Tipo de proxy recomendado | Por que |
|---|---|---|
| Geopreços e conteúdo | Residenciais | Parecem tráfego de um usuário comum, não acionam proteção contra bots |
| Geobloqueios | Residenciais | Geolocalização precisa até a cidade/região |
| A/B e rollouts | Residenciais / data center | Sessão estável durante todo o ciclo de teste |
| Push e localização | Móveis | Reproduzem condições reais de entrega através de operadoras |
| Pagamentos e antifraude | Residenciais / móveis | Baixo risco de falsos positivos em sistemas antifraude |
| Redes móveis de operadoras | Móveis | SIM cards reais de operadoras, emulação precisa de NAT e latências |
| Limitação de taxa / testes de carga | Data center | Alta velocidade e baixo custo em grandes volumes de solicitações |
Checklist antes do lançamento
Antes de liberar a versão para produção, passe por uma lista curta de verificações relacionadas à geolocalização e rede — isso cobre a maioria dos bugs descritos acima:
- Preços e moeda da assinatura verificados em pelo menos 5 mercados-chave do produto
- Exibição correta da tela de geobloqueio em países proibidos verificada
- Feature flag testada no país da primeira onda de rollout antes do lançamento global
- Notificações push verificadas com IP e idioma do sistema de diferentes combinações de países
- Métodos de pagamento disponíveis verificados para cada região-chave separadamente
- Fluxo de pagamento testado sem falsos positivos em sistemas antifraude
- Aplicativo testado em condições de rede móvel (3G/4G), e não apenas Wi-Fi
- Testes automatizados não falham devido à limitação de taxa durante a execução paralela de um único IP
Conclusão
Um aplicativo móvel vive em dezenas de países, redes e ecossistemas de pagamento ao mesmo tempo, enquanto a equipe de QA fisicamente está em um único escritório com um único IP. É exatamente essa lacuna entre a audiência real e as condições de teste que gera a maioria dos bugs "inexplicáveis" que chegam à produção. Os sete cenários acima — geoc preços, geobloqueios, rollouts A/B, push e localização, pagamentos, redes móveis de operadoras e limitação de taxa — cobrem a maior parte desses riscos.
Se sua equipe está testando um aplicativo que trabalha com conteúdo regional, preços ou pagamentos, é sensato conectar proxies residenciais ao stack de teste para simular usuários reais, e para cenários com conexão móvel e entrega de push — proxies móveis vinculados a operadoras específicas. Isso permite encontrar bugs críticos na fase de QA, e não após as reclamações dos usuários nas lojas.