Testar seu produto como se estivesse em outro país

Seu produto atende outros países, mas todo mundo do time acessa do Brasil. A consequência é previsível: bugs de localização só aparecem quando um cliente de fora reclama, e aí você depende dele para reproduzir.

Dá para olhar do lugar do usuário estrangeiro sem viajar e sem pedir favor para conhecido. Este é o roteiro.

Três camadas, três ferramentas

Ver o produto como alguém de fora exige mudar três coisas, e cada uma pede uma ferramenta diferente:

De onde a requisição parece vir — proxy no país alvo. Afeta geolocalização por IP, moeda, idioma padrão, conteúdo regional, e qualquer bloqueio por região.

Que telefone recebe o SMS — número virtual daquele país. Afeta cadastro, verificação e o formato da mensagem.

Que rede móvel o aparelho usa — eSIM da operadora local. Afeta o que só se vê em conexão móvel real.

A maioria dos testes precisa só da primeira. Quem tem cadastro por telefone precisa das duas primeiras. A terceira é para caso específico.

O que quebra e você não vê daqui

Moeda e formato de número. 1.234,56 e 1,234.56 invertidos é o erro clássico. Também data: 03/04 é março ou abril, dependendo de quem lê.

Idioma que não é o que você espera. O serviço de verificação manda a mensagem no idioma do país do número. Se você extrai o código com uma expressão que espera texto em português, quebra em silêncio — testar cadastro com números de vários países revela isso antes do cliente.

Fuso. Agendamento, expiração e "hoje" mudam de significado. Um cupom que vence "às 23:59" vence quando, exatamente?

Conteúdo por região. Preço, disponibilidade, aviso legal. Se você tem lógica por país, ela precisa ser exercitada de fora, não com um parâmetro forçado em desenvolvimento.

Latência real. Sua página abre rápido porque o servidor está perto. De outro continente, com três vezes mais latência, aquele carregamento em cascata que ninguém notou vira espera visível.

Escolhendo o proxy certo

Não é sobre qualidade, é sobre o que o destino consegue enxergar da conexão — a comparação entre residencial, datacenter e móvel resolve a escolha. Para testar o seu próprio produto, datacenter costuma bastar e é o mais barato: você não está tentando parecer um usuário orgânico, só quer sair pelo IP de outro país.

Se o seu produto tem antifraude que reage a IP de datacenter, aí você precisa de residencial — porque é justamente esse comportamento que você quer testar.

Encaixando no processo

No CI, para o que é determinístico. Formatação, idioma da interface, cálculo de preço por região. Roda rápido, não depende de terceiro.

Manual, antes de lançar em país novo. Uma passada de olho pelo fluxo inteiro com proxy e número daquele país. Meia hora que encontra o que nenhum teste automatizado pega, porque ninguém pensou em escrever.

Sob demanda, quando chega bug. Cliente da Alemanha reclama de algo que você não reproduz? Reproduza do jeito dele antes de responder que não conseguiu.

O erro de método mais comum

Testar com um parâmetro forçado (?country=de) em vez de sair de verdade pelo país. Isso testa o seu código de localização, não o caminho real: não passa pela detecção por IP, não passa pelo CDN da região, não pega o que o proxy reverso decide antes da sua aplicação.

Serve para desenvolvimento. Não serve como prova de que funciona.

Custo

Menor do que parece, porque o uso é pontual: número cobrado por verificação concluída — e número que não recebe código não é cobrado. Uma bateria de testes em cinco países custa menos que uma hora de desenvolvimento.

Comparado ao custo de descobrir pelo cliente, não há discussão.

Hoje os números virtuais já estão disponíveis; o proxy está em preparação.