Il team testa l'applicazione per un intero sprint, rilascia la build — e dopo una settimana arrivano lamentele al supporto: «nel mio paese il prezzo è diverso», «la notifica push non è arrivata», «non riesco a pagare con la carta». La causa è quasi sempre la stessa: tutti i test sono stati eseguiti da un unico IP aziendale, mentre gli utenti reali accedono da altre regioni, reti e operatori. In questo articolo analizzeremo 7 scenari di QA concreti che non possono essere fisicamente testati senza cambiare l'indirizzo IP e mostreremo come configurare l'infrastruttura di test con un proxy.
Perché l'IP aziendale è una zona cieca per il QA
La maggior parte delle applicazioni mobili oggi prende decisioni basate sull'indirizzo IP: determinano il paese dell'utente, la lingua dell'interfaccia, la valuta, i metodi di pagamento disponibili, il set di funzionalità e persino il prezzo dell'abbonamento. Quando l'intero dipartimento QA testa da un'unica sede con un IP statico del data center o della rete aziendale, l'applicazione riceve sempre la stessa risposta dal backend — come se tutti i tester si trovassero in un unico punto del mondo.
Di conseguenza, i bug che dipendono dalla geolocalizzazione, dall'ora nel fuso orario, dall'operatore di rete o dal tipo di connessione, semplicemente non si riproducono nell'ambiente di test. Emergeranno solo in produzione — quando un utente dal Kazakistan vede i prezzi in rubli, un utente tedesco non riceve la notifica push a causa del blocco GCM nella sua rete, e un cliente indonesiano non può pagare con la carta perché il fornitore di pagamenti per la sua regione non è attivo. Correggere un bug di questo tipo dopo il rilascio costa molte volte di più che catturarlo nella fase di QA.
La soluzione è emulare la reale diversità geografica e di rete degli utenti prima del rilascio. Per questo motivo, gli ingegneri QA utilizzano sempre più spesso i server proxy: consentono di "spostare" il dispositivo di test o l'emulatore in qualsiasi paese, città o anche operatore di rete senza la necessità di recarsi fisicamente lì o acquistare decine di SIM.
Scenario 1: Geocontenuti e prezzi regionali
La maggior parte delle applicazioni con abbonamenti (streaming, fitness, istruzione) mostrano prezzi diversi in diversi paesi — questo è chiamato geopricing. Se il QA verifica la registrazione all'abbonamento solo da un IP locale, non è possibile assicurarsi che il prezzo per un utente dalla Turchia, dal Brasile o dall'India venga visualizzato correttamente, nella valuta giusta e con l'arrotondamento corretto.
Lo stesso problema si presenta con i cataloghi di contenuti: la biblioteca di film, prodotti o promozioni è spesso regionale. È necessario "apparire" fisicamente nel paese giusto per vedere lo stesso schermo che vede un utente reale. Per tali verifiche è conveniente utilizzare proxy residenziali — forniscono IP di utenti domestici reali di un determinato paese, e il backend dell'applicazione percepisce la richiesta come traffico organico normale, e non come una richiesta da un data center.
Controllo pratico: eseguiamo lo scenario di registrazione all'abbonamento in 8-10 mercati chiave (USA, Germania, Brasile, India, Turchia, Giappone, Nigeria, UAE), registriamo screenshot del prezzo e della valuta, e confrontiamo con il listino prezzi del prodotto. Questo chiude gran parte delle lamentele del tipo «perché ho un prezzo diverso».
Scenario 2: Geoblocchi e restrizioni di accesso
Le applicazioni fintech, i servizi di streaming e alcuni giochi bloccano l'accesso da determinati paesi per motivi legali o di licenza. Il QA deve assicurarsi non solo che l'applicazione funzioni dove deve, ma anche che rifiuti correttamente (e non con un crash) l'accesso dove non deve.
Un bug tipico: invece di un elegante schermo "servizio non disponibile nella tua regione", l'utente vede uno schermo bianco o un caricamento infinito — perché gli sviluppatori hanno testato solo il percorso positivo da un paese autorizzato. Verificare i geoblocchi richiede collegamenti sequenziali da diverse giurisdizioni vietate, il che è irrealistico con SIM reali e viaggi, mentre tramite proxy richiede 10-15 minuti per paese.
Per questo scenario, sono adatti proxy con geolocalizzazione precisa a livello di città, e non solo di paese — è importante controllare non "la Germania in generale", ma terre specifiche, se la licenza è limitata a una regione all'interno del paese.
Scenario 3: A/B e rollout graduali per paesi
I feature flag e i rollout graduali sono quasi sempre impostati con riferimento alla geolocalizzazione: una nuova funzione viene attivata prima in Canada, dopo una settimana in Australia, e poi ovunque. Se il team QA si trova fisicamente in un solo paese, non può vedere la nuova versione prima degli altri regioni, finché il flag non arriva anche a loro.
Per testare una funzione prima del rilascio globale, è necessario sostituire la geolocalizzazione con il paese della prima ondata di rollout. Questo è uno dei compiti più comuni che i proxy risolvono in combinazione con browser anti-detect o emulatori di dispositivi — cambiamo l'IP nel paese desiderato, riavviamo la sessione dell'applicazione, vediamo la funzione prima degli altri utenti e abbiamo il tempo di trovare bug prima che il flag arrivi al 100% del pubblico.
Un punto importante: per i test A/B è necessaria una "residenza" stabile dell'IP per l'intero ciclo di test — la sessione non deve saltare tra i paesi tra le richieste, altrimenti il backend confonderà le condizioni dell'esperimento e mostrerà ora il gruppo di controllo, ora quello di test.
Scenario 4: Localizzazione e notifiche push
Il testo della notifica push, il momento della sua invio e persino il fatto stesso della consegna dipendono spesso dalla geolocalizzazione del dispositivo. In alcuni paesi, i provider di push (Firebase, APNs, gateway SMS locali) funzionano con ritardi o attraverso percorsi alternativi — e ciò che viene consegnato perfettamente nell'ambiente di test dall'ufficio di Mosca, potrebbe non arrivare all'utente in Indonesia a causa del blocco di determinati server push da parte del provider di rete locale.
Inoltre, la localizzazione dell'interfaccia spesso viene attivata proprio dall'IP, e non solo dalla lingua del sistema: un utente con la lingua inglese sul telefono, ma con IP dalla Francia, può vedere un'interfaccia mista — intestazioni in francese, pulsanti in inglese. Questi bug sono invisibili al 100% se tutto il QA testa da una sola geozona.
Processo consigliato: prendiamo 5-7 lingue da mercati prioritari del prodotto, ci colleghiamo tramite proxy con l'IP corrispondente, cambiamo la lingua del sistema sul dispositivo/emulatore e registriamo quale testo e formato di date/numeri mostra l'applicazione. Le discrepanze tra l'IP del paese e la lingua del sistema sono un caso obbligatorio separato, spesso vengono dimenticate.
Scenario 5: Metodi di pagamento e sistemi antifrode
Il set di metodi di pagamento disponibili in un'app mobile dipende quasi sempre dal paese: in una regione è disponibile il pagamento con carta e Apple Pay, in un'altra solo portafogli locali (Mercado Pago, Boleto, UPI, QIWI), in una terza il pagamento tramite operatore di rete. Se il QA non può collegarsi dal paese richiesto, metà degli scenari di pagamento rimane non testata fino alla produzione, dove il prezzo dell'errore è la perdita di entrate e le lamentele al supporto.
Un'altra difficoltà è rappresentata dai sistemi antifrode dei fornitori di pagamento. Questi valutano il rischio della transazione anche in base all'IP: una richiesta da un IP di data center quasi sicuramente riceverà un rifiuto o un ulteriore controllo 3D-Secure, anche se la carta è assolutamente valida. Questo distorce i risultati dei test: il QA vede un rifiuto nel pagamento e segnala un bug agli sviluppatori, mentre il problema non è nel codice, ma nel fatto che l'IP di test appare sospetto per il punteggio antifrode.
Per gli scenari di pagamento, è meglio utilizzare proxy residenziali o proxy mobili — sembrano traffico normale di un utente reale e non attivano attivazioni indesiderate dei sistemi antifrode, il che fornisce un quadro più onesto del comportamento del flusso di pagamento.
Scenario 6: Comportamento nelle reti mobili degli operatori
Un'app che funziona perfettamente nel Wi-Fi aziendale a 200 Mbit/s può comportarsi in modo completamente diverso in una rete mobile 3G/4G con connessione instabile, proxy NAT dell'operatore e alta latenza. Timeout delle richieste, tentativi ripetuti, degrado della qualità video/audio, funzionamento della modalità offline — tutto questo è critico da verificare proprio in condizioni vicine a quelle di internet mobile, e non in una rete aziendale stabile.
Ulteriore complessità: alcuni operatori di rete applicano i propri proxy e CGNAT, a causa dei quali il server vede non l'IP reale dell'utente, ma l'IP condiviso dell'operatore, attraverso il quale passano migliaia di abbonati contemporaneamente. Questo influisce sul rate limiting e sulla geolocalizzazione tramite IP — l'app potrebbe "pensare" che l'utente si trovi in un'altra città rispetto a dove si trova fisicamente.
Per riprodurre tale comportamento, sono necessari proprio proxy mobili, che accedono a internet tramite SIM reali degli operatori del paese richiesto — questo fornisce un quadro preciso di NAT, latenza e velocità, che non si ottiene con un normale IP di data center.
Scenario 7: Rate limiting e protezione dai bot
Molti API backend delle applicazioni mobili limitano il numero di richieste da un singolo IP (rate limiting) e utilizzano protezioni contro i bot, simili a captcha o analisi comportamentale. Se il team QA esegue test automatici da un unico IP aziendale, dopo un certo tempo il server inizia a rispondere con errori 429 o blocca completamente le richieste — e i test falliscono non a causa di un bug nell'applicazione, ma perché il backend ha interpretato il traffico di test come un attacco.
Questo è particolarmente rilevante per i test di carico e regressione, quando in breve tempo è necessario eseguire centinaia di richieste simili (registrazione, login, aggiunta al carrello). Distribuire le richieste tra diversi IP tramite un pool di proxy consente di caricare onestamente l'API senza distorcere i risultati a causa dell'attivazione della protezione antifrode.
Per questo tipo di test automatizzati su larga scala, è spesso più vantaggioso utilizzare proxy di data center — sono più veloci e più economici per grandi volumi di richieste, e la geolocalizzazione in questo scenario non è così critica come la velocità e la stabilità della connessione.
Strumenti e configurazione del proxy per il QA
Per il QA manuale su emulatori (Android Studio Emulator, Xcode Simulator) il proxy viene configurato tramite le impostazioni di rete di sistema dell'emulatore: si specificano l'IP e la porta del server proxy, il login e la password, se viene utilizzata l'autenticazione. Per i dispositivi reali, impostazioni simili sono disponibili nella connessione Wi-Fi tramite "Impostazioni avanzate → Proxy → Manualmente".
Per intercettare e analizzare il traffico tra l'applicazione e il backend, gli ingegneri QA utilizzano Charles Proxy o Proxyman — entrambi gli strumenti consentono di far passare il traffico dell'applicazione attraverso un proxy esterno e vedere contemporaneamente tutte le richieste HTTP/HTTPS, le intestazioni di geolocalizzazione e le risposte del server. Questo è utile per la diagnosi: è subito chiaro quale IP e quale paese "vede" il backend al momento della richiesta.
Per i test automatizzati tramite Appium o Espresso, il proxy viene specificato nelle capacità desiderate della sessione o tramite le impostazioni di sistema del dispositivo prima di avviare il set di test. Le piattaforme cloud per il test delle applicazioni mobili (BrowserStack, Sauce Labs) supportano anche la connessione di proxy personalizzati, il che consente di eseguire lo stesso scenario di test automatico da diversi paesi senza dispositivi fisici in ogni punto del mondo.
Se nel team c'è una versione web dell'applicazione o è necessario testare parallelamente più account con geolocalizzazioni diverse, è conveniente utilizzare browser anti-detect (Dolphin Anty, AdsPower, Multilogin) — ogni profilo è collegato a un proxy separato, e l'ingegnere QA può mantenere aperte 5-10 sessioni da diversi paesi contemporaneamente senza confusione nei cookie e nella cache.
Quale tipo di proxy scegliere per ogni scenario
| Scenario QA | Tipo di proxy raccomandato | Perché |
|---|---|---|
| Geoprezzi e contenuti | Residenziali | Appaiono come traffico di un utente normale, non attivano la protezione anti-bot |
| Geoblocchi | Residenziali | Geolocalizzazione precisa fino alla città/regione |
| A/B e rollout | Residenziali / data center | Sessione stabile per l'intero ciclo di test |
| Notifiche push e localizzazione | Mobili | Riproducono le reali condizioni di consegna tramite operatori |
| Pagamenti e antifrode | Residenziali / mobili | Basso rischio di falsi positivi nei sistemi antifrode |
| Reti mobili degli operatori | Mobili | SIM reali degli operatori, emulazione precisa di NAT e latenza |
| Rate limiting / test di carico | Data center | Alta velocità e basso costo per grandi volumi di richieste |
Checklist prima del rilascio
Prima di rilasciare la build in produzione, controlla un breve elenco di verifiche relative alla geolocalizzazione e alla rete — questo chiude la maggior parte dei bug descritti sopra:
- Prezzi e valuta dell'abbonamento verificati in almeno 5 mercati chiave del prodotto
- Verificata la corretta visualizzazione dello schermo di geoblocco nei paesi vietati
- Feature flag testato nel paese della prima ondata di rollout prima del rilascio globale
- Notifiche push verificate con IP e lingua di sistema da diverse combinazioni di paesi
- Metodi di pagamento disponibili verificati per ogni regione chiave separatamente
- Flusso di pagamento testato senza falsi positivi nei sistemi antifrode
- Applicazione testata in condizioni di rete mobile (3G/4G), e non solo Wi-Fi
- I test automatici non falliscono a causa del rate limiting durante l'esecuzione parallela da un unico IP
Conclusione
Un'app mobile vive in decine di paesi, reti e ecosistemi di pagamento contemporaneamente, mentre il team QA si trova fisicamente in un unico ufficio con un solo IP. È proprio questo divario tra il pubblico reale e le condizioni di test che genera la maggior parte dei bug "inspiegabili" che arrivano in produzione. I sette scenari sopra — geoprezzi, geoblocchi, rollout A/B, notifiche push e localizzazione, pagamenti, reti mobili degli operatori e rate limiting — coprono la maggior parte di tali rischi.
Se il tuo team testa un'app che lavora con contenuti regionali, prezzi o pagamenti, è sensato integrare nel tuo stack di test proxy residenziali per simulare utenti reali, e per scenari con rete mobile e consegna di notifiche push — proxy mobili legati a operatori specifici. Questo consente di trovare bug critici nella fase di QA, e non dopo le lamentele degli utenti negli store.