El equipo prueba la aplicación durante todo un sprint, lanza la versión — y a la semana empiezan a llegar quejas al soporte: "en mi ciudad el precio es diferente", "no llegó la notificación push", "no puedo pagar con tarjeta". La razón casi siempre es la misma: todas las pruebas se realizaron desde una única IP corporativa, mientras que los usuarios reales acceden desde otras regiones, redes y operadores. En este artículo, analizaremos 7 escenarios específicos de QA que son físicamente imposibles de verificar sin cambiar la dirección IP, y mostraremos cómo configurar la infraestructura de prueba con proxies.
Por qué la IP de oficina es una zona ciega para QA
La mayoría de las aplicaciones móviles hoy en día toman decisiones basadas en la dirección IP: determinan el país del usuario, el idioma de la interfaz, la moneda, los métodos de pago disponibles, el conjunto de funciones e incluso el precio de la suscripción. Cuando todo el departamento de QA prueba desde una única oficina con una IP estática de un centro de datos o de una red corporativa, la aplicación siempre recibe la misma respuesta del backend — como si todos los testers estuvieran en un solo punto del mundo.
Como resultado, los errores que dependen de la geolocalización, la hora en la zona horaria, el operador de telecomunicaciones o el tipo de conexión, simplemente no se reproducen en el entorno de prueba. Aparecen solo en producción — cuando un usuario de Kazajistán ve precios en rublos, un usuario alemán no recibe la notificación push debido al bloqueo de GCM en su red, y un cliente indonesio no puede pagar con tarjeta porque el proveedor de pagos para su región no está conectado. Corregir un error de este tipo después del lanzamiento cuesta mucho más que detectarlo en la etapa de QA.
La solución es emular la verdadera diversidad geográfica y de red de los usuarios antes del lanzamiento. Para esto, los ingenieros de QA utilizan cada vez más servidores proxy: permiten "mover" el dispositivo de prueba o el emulador a cualquier país, ciudad o incluso operador de telecomunicaciones sin necesidad de viajar físicamente allí o comprar decenas de tarjetas SIM.
Escenario 1: Geocontenido y precios regionales
La mayoría de las aplicaciones con suscripciones (streaming, fitness, educación) muestran diferentes precios en diferentes países — esto se llama geoprecio. Si QA verifica la suscripción solo desde una IP local, no es posible asegurarse de que el precio para un usuario de Turquía, Brasil o India se muestra correctamente, en la moneda correcta y con el redondeo adecuado.
El mismo problema ocurre con los catálogos de contenido: la biblioteca de películas, productos o promociones a menudo es regional. Es necesario "aparecer" físicamente en el país correspondiente para ver la misma pantalla que ve un usuario real. Para tales verificaciones, es conveniente utilizar proxies residenciales — proporcionan IP de usuarios domésticos reales de un país específico, y el backend de la aplicación percibe la solicitud como tráfico orgánico normal, y no como una solicitud de un centro de datos.
Verificación práctica: ejecutamos el escenario de suscripción en 8-10 mercados clave (EE. UU., Alemania, Brasil, India, Turquía, Japón, Nigeria, EAU), tomamos capturas de pantalla del precio y la moneda, y las comparamos con la lista de precios del producto. Esto cubre la mayor parte de las quejas del tipo "¿por qué tengo un precio diferente?".
Escenario 2: Geobloqueos y restricciones de acceso
Las aplicaciones fintech, los servicios de streaming y algunos juegos bloquean el acceso desde ciertos países por razones legales o de licencia. QA debe asegurarse no solo de que la aplicación funcione donde debe, sino también de que rechace correctamente (y no con un fallo) el acceso donde no debe.
Un error típico: en lugar de una pantalla ordenada que dice "el servicio no está disponible en su región", el usuario ve una pantalla blanca o un cargador infinito — porque los desarrolladores solo probaron el camino feliz desde un país permitido. Verificar los geobloqueos requiere conectarse secuencialmente desde varias jurisdicciones prohibidas, lo cual es poco realista con tarjetas SIM reales y viajes de negocios, pero a través de proxies toma de 10 a 15 minutos por país.
Para este escenario, son adecuados los proxies con geolocalización precisa a nivel de ciudad, y no solo de país — es importante verificar no "Alemania en general", sino tierras específicas, si la licencia está restringida a una región dentro del país.
Escenario 3: A/B y despliegues escalonados por países
Las banderas de funciones y los despliegues escalonados casi siempre se configuran con base en la geolocalización: una nueva función se activa primero en Canadá, una semana después en Australia, y luego en todas partes. Si el equipo de QA se encuentra físicamente en un solo país, no puede ver la nueva versión antes que el resto de las regiones, hasta que la bandera llegue a ellos.
Para probar una función antes del lanzamiento global, es necesario cambiar la geolocalización al país de la primera ola de despliegue. Esta es una de las tareas más comunes que resuelven los proxies en combinación con navegadores anti-detección o emuladores de dispositivos — cambiamos la IP al país deseado, reiniciamos la sesión de la aplicación, vemos la función antes que los demás usuarios y tenemos tiempo para encontrar errores antes de que la bandera llegue al 100% de la audiencia.
Un matiz importante: para las pruebas A/B se necesita una "residencia" estable de la IP durante todo el ciclo de prueba — la sesión no debe saltar entre países entre solicitudes, de lo contrario, el backend confundirá las condiciones del experimento y mostrará a veces el grupo de control y otras veces el grupo de prueba.
Escenario 4: Localización y notificaciones push
El texto de la notificación push, el momento de su envío e incluso el hecho mismo de la entrega a menudo dependen de la geolocalización del dispositivo. En algunos países, los proveedores de notificaciones push (Firebase, APNs, puertas SMS locales) funcionan con retrasos o a través de rutas alternativas — y lo que se entrega perfectamente en un entorno de prueba desde una oficina en Moscú, puede no llegar al usuario en Indonesia debido al bloqueo de servidores push específicos por parte del proveedor de telecomunicaciones local.
Además, la localización de la interfaz a menudo se activa precisamente por IP, y no solo por el idioma del sistema: un usuario con un teléfono en inglés, pero con IP de Francia, puede ver una interfaz mixta — encabezados en francés, botones en inglés. Tales errores son 100% invisibles si todo el QA prueba desde una sola zona geográfica.
Proceso recomendado: tomamos 5-7 locales de los mercados prioritarios del producto, nos conectamos a través de proxies con la IP correspondiente, cambiamos el idioma del sistema en el dispositivo/emulador y registramos qué texto y formato de fechas/números muestra la aplicación. Las discrepancias entre la IP del país y el idioma del sistema son un caso obligatorio separado, que a menudo se olvida.
Escenario 5: Métodos de pago y sistemas antifraude
El conjunto de métodos de pago disponibles en una aplicación móvil casi siempre depende del país: en una región se permite el pago con tarjeta y Apple Pay, en otra — solo billeteras locales (Mercado Pago, Boleto, UPI, QIWI), en una tercera — el pago a través del operador de telecomunicaciones. Si QA no puede conectarse desde el país necesario, la mitad de los escenarios de pago quedan sin verificar hasta la producción, donde el costo del error es la pérdida de ingresos y quejas al soporte.
Un dolor adicional son los sistemas antifraude de los proveedores de pagos. Evalúan el riesgo de la transacción también por IP: una solicitud desde la IP de un centro de datos casi seguramente recibirá un rechazo o una verificación adicional de 3D-Secure, incluso si la tarjeta es absolutamente válida. Esto distorsiona los resultados de las pruebas: QA ve un rechazo en el pago y reporta un error a los desarrolladores, aunque el problema no está en el código, sino en que la IP de prueba parece sospechosa para la puntuación antifraude.
Para escenarios de pago, es mejor utilizar proxies residenciales o proxies móviles — parecen tráfico normal de un usuario real y no activan alertas innecesarias en los sistemas antifraude, lo que proporciona una imagen más honesta del comportamiento del flujo de pago.
Escenario 6: Comportamiento en redes móviles de operadores
Una aplicación que funciona perfectamente en el Wi-Fi de oficina a 200 Mbps, puede comportarse de manera completamente diferente en una red móvil 3G/4G con una conexión inestable, un proxy NAT del operador y alta latencia. Los tiempos de espera de las solicitudes, los reintentos, la degradación de la calidad de video/audio, el funcionamiento del modo offline — todo esto es crítico verificar en condiciones cercanas a Internet móvil, y no solo en una red de oficina estable.
Complejidad adicional: algunos operadores de telecomunicaciones aplican sus propios proxies y CGNAT, lo que hace que el servidor vea no la IP real del usuario, sino la IP compartida del operador, a través de la cual pasan miles de abonados simultáneamente. Esto afecta la limitación de tasa y la geolocalización por IP — la aplicación puede "pensar" que el usuario se encuentra en otra ciudad, de lo que realmente está físicamente.
Para reproducir tal comportamiento, se necesitan proxies móviles que salgan a Internet a través de tarjetas SIM reales de los operadores del país necesario — esto proporciona una imagen precisa de NAT, latencias y velocidades, que no se puede obtener con una IP de centro de datos normal.
Escenario 7: Limitación de tasa y protección contra bots
Muchas API de backend de aplicaciones móviles limitan la cantidad de solicitudes desde una IP (limitación de tasa) y utilizan protección contra bots, similar a un captcha o análisis de comportamiento. Si el equipo de QA ejecuta pruebas automatizadas desde una única IP corporativa, después de un tiempo el servidor comienza a responder con errores 429 o bloquea las solicitudes por completo — y las pruebas fallan no por un error en la aplicación, sino porque el backend ha interpretado el tráfico de prueba como un ataque.
Esto es especialmente relevante para pruebas de carga y regresión, cuando en un corto período de tiempo se deben realizar cientos de solicitudes similares (registro, inicio de sesión, agregar al carrito). Distribuir las solicitudes entre diferentes IP a través de un grupo de proxies permite cargar la API de manera justa sin distorsionar los resultados debido a la activación de la protección antifraude.
Para este tipo de pruebas automatizadas masivas, a menudo es más rentable utilizar proxies de centros de datos — son más rápidos y más baratos con grandes volúmenes de solicitudes, y la geolocalización en este escenario no es tan crítica como la velocidad y estabilidad de la conexión.
Herramientas y configuración de proxies para QA
Para QA manual en emuladores (Android Studio Emulator, Xcode Simulator), el proxy se configura a través de la configuración de red del emulador: se indica la IP y el puerto del servidor proxy, el nombre de usuario y la contraseña, si se utiliza autenticación. Para dispositivos reales, configuraciones similares están disponibles en la conexión Wi-Fi a través de "Configuraciones avanzadas → Proxy → Manualmente".
Para interceptar y analizar el tráfico entre la aplicación y el backend, los ingenieros de QA utilizan Charles Proxy o Proxyman — ambas herramientas permiten pasar el tráfico de la aplicación a través de un proxy externo y ver simultáneamente todas las solicitudes HTTP/HTTPS, encabezados de geolocalización y respuestas del servidor. Esto es conveniente para el diagnóstico: se puede ver de inmediato qué IP y qué país "ve" el backend en el momento de la solicitud.
Para pruebas automatizadas a través de Appium o Espresso, el proxy se indica en las capacidades deseadas de la sesión o a través de la configuración del dispositivo antes de ejecutar el conjunto de pruebas. Las plataformas en la nube para pruebas de aplicaciones móviles (BrowserStack, Sauce Labs) también admiten la conexión de proxies personalizados, lo que permite ejecutar el mismo escenario de prueba automatizada desde diferentes países sin dispositivos físicos en cada punto del mundo.
Si en el equipo hay una versión web de la aplicación o es necesario probar varios cuentas con diferentes geolocalizaciones simultáneamente, es conveniente utilizar navegadores anti-detección (Dolphin Anty, AdsPower, Multilogin) — cada perfil se vincula a un proxy separado, y el ingeniero de QA puede mantener abiertas de 5 a 10 sesiones de diferentes países al mismo tiempo sin confusión en las cookies y caché.
Qué tipo de proxy elegir para cada escenario
| Escenario de QA | Tipo de proxy recomendado | Por qué |
|---|---|---|
| Geoprecios y contenido | Residenciales | Parecen tráfico de un usuario normal, no activan la protección antifraude |
| Geobloqueos | Residenciales | Geolocalización precisa hasta la ciudad/región |
| A/B y despliegues | Residenciales / centros de datos | Sesión estable durante todo el ciclo de prueba |
| Notificaciones push y localización | Móviles | Reproducen condiciones reales de entrega a través de operadores |
| Pagos y antifraude | Residenciales / móviles | Bajo riesgo de falsas alarmas en sistemas antifraude |
| Redes móviles de operadores | Móviles | Tarjetas SIM reales de operadores, emulación precisa de NAT y latencias |
| Limitación de tasa / pruebas de carga | Centros de datos | Alta velocidad y bajo costo con grandes volúmenes de solicitudes |
Lista de verificación antes del lanzamiento
Antes de liberar la versión a producción, revisa una breve lista de verificaciones relacionadas con la geolocalización y la red — esto cubre la mayoría de los errores descritos anteriormente:
- Se han verificado los precios y la moneda de la suscripción en al menos 5 mercados clave del producto
- Se ha verificado la correcta visualización de la pantalla de geobloqueo en países prohibidos
- La bandera de función se ha probado en el país de la primera ola de despliegue antes del lanzamiento global
- Las notificaciones push se han verificado con IP y idioma del sistema de diferentes combinaciones de países
- Los métodos de pago disponibles se han verificado para cada región clave por separado
- El flujo de pago se ha probado sin falsas alarmas en los sistemas antifraude
- La aplicación se ha probado en condiciones de red móvil (3G/4G), y no solo Wi-Fi
- Las pruebas automatizadas no fallan debido a la limitación de tasa al ejecutarse en paralelo desde una IP
Conclusión
Una aplicación móvil vive en decenas de países, redes y ecosistemas de pago al mismo tiempo, mientras que el equipo de QA se encuentra físicamente en una oficina con una única IP. Esta brecha entre la audiencia real y las condiciones de prueba genera la mayoría de los errores "inexplicables" que llegan a producción. Los siete escenarios anteriores — geoprecios, geobloqueos, despliegues A/B, notificaciones push y localización, pagos, redes móviles de operadores y limitación de tasa — cubren la mayor parte de esos riesgos.
Si su equipo está probando una aplicación que trabaja con contenido, precios o pagos regionales, es razonable incluir en el stack de pruebas proxies residenciales para simular usuarios reales, y para escenarios con conectividad móvil y entrega de notificaciones push — proxies móviles vinculados a operadores específicos. Esto permite encontrar errores críticos en la etapa de QA, y no después de las quejas de los usuarios en las tiendas.