Ekip uygulamayı bir sprint boyunca test ediyor, derlemeyi yayımlıyor - bir hafta sonra destek hattına şikayetler yağıyor: "benim şehrimde fiyat farklı", "bildirim gelmedi", "kartla ödeme yapamıyorum". Neden neredeyse her zaman aynıdır: tüm testler tek bir kurumsal IP üzerinden yapıldı, oysa gerçek kullanıcılar farklı bölgelerden, ağlardan ve operatörlerden giriş yapıyor. Bu yazıda, IP adresini değiştirmeden fiziksel olarak test edilemeyecek 7 spesifik QA senaryosunu inceleyeceğiz ve proxy ile test altyapısını nasıl ayarlayacağımızı göstereceğiz.
Neden ofis IP'si QA için kör nokta
Günümüzde çoğu mobil uygulama, IP adresine dayalı kararlar alıyor: kullanıcının ülkesini, arayüz dilini, para birimini, mevcut ödeme yöntemlerini, özellik setini ve hatta abonelik fiyatını belirliyor. Tüm QA departmanı, tek bir ofisten, bir statik IP üzerinden test yaptığında, uygulama her zaman backend'den aynı yanıtı alır - sanki tüm test mühendisleri dünyanın tek bir noktasındaymış gibi.
Sonuç olarak, coğrafi konuma, saat dilimine, iletişim operatörüne veya bağlantı türüne bağlı hatalar, test ortamında basitçe yeniden üretilmez. Bu hatalar yalnızca üretimde ortaya çıkar - Kazakistan'dan bir kullanıcı ruble cinsinden fiyatları görürken, Alman bir kullanıcı GCM engeli nedeniyle bildirim almaz ve Endonezyalı bir müşteri, kendi bölgesi için ödeme sağlayıcısı bağlı olmadığı için kartla ödeme yapamaz. Bu tür bir hatanın düzeltmesi, QA aşamasında yakalamaktan çok daha pahalıdır.
Çözüm, gerçek coğrafi ve ağ çeşitliliğini, yayımdan önce simüle etmektir. Bu nedenle QA mühendisleri, test cihazını veya emülatörü herhangi bir ülkeye, şehre veya hatta iletişim operatörüne "taşımalarına" olanak tanıyan proxy sunucularını giderek daha fazla kullanıyor.
Senaryo 1: Coğrafi içerik ve bölgesel fiyatlar
Abonelik içeren çoğu uygulama (streaming, fitness, eğitim) farklı ülkelerde farklı fiyatlar gösterir - buna coğrafi fiyatlandırma denir. QA, abonelik kaydını yalnızca yerel bir IP ile kontrol ederse, Türkiye, Brezilya veya Hindistan'dan bir kullanıcı için fiyatın doğru görüntülendiğinden, doğru para biriminde ve doğru yuvarlama ile göründüğünden emin olamaz.
İçerik katalogları ile de aynı sorun var: film, ürün veya kampanya kütüphanesi genellikle bölgeseldir. Gerçek bir kullanıcının gördüğü aynı ekranı görmek için fiziksel olarak ilgili ülkede "bulunmak" gerekir. Bu tür kontroller için rezidans proxy'leri kullanmak uygundur - bunlar belirli bir ülkenin gerçek ev kullanıcılarının IP'sini sağlar ve uygulamanın backend'i isteği normal organik trafik olarak algılar, veri merkezinden gelen bir istek olarak değil.
Pratik kontrol: 8-10 ana pazarda (ABD, Almanya, Brezilya, Hindistan, Türkiye, Japonya, Nijerya, BAE) abonelik kaydı senaryosunu çalıştırıyoruz, fiyat ve para birimi ekran görüntülerini kaydediyoruz, ürün fiyat listesi ile karşılaştırıyoruz. Bu, "neden bende farklı bir fiyat var" gibi şikayetlerin büyük bir kısmını kapatır.
Senaryo 2: Coğrafi engellemeler ve erişim kısıtlamaları
Fintech uygulamaları, streaming hizmetleri ve bazı oyunlar, yasal veya lisans nedenleriyle belirli ülkelerden erişimi engeller. QA, uygulamanın olması gereken yerlerde çalıştığından emin olmalı, aynı zamanda olmaması gereken yerlerde erişimi düzgün bir şekilde (çökme olmadan) reddettiğinden de emin olmalıdır.
Tipik bir hata: kullanıcı, "hizmet bölgenizde mevcut değil" ekranı yerine beyaz bir ekran veya sonsuz bir yükleme ekranı görür - çünkü geliştiriciler yalnızca izin verilen ülkeden gelen happy path'i test etmiştir. Coğrafi engellerin kontrolü, birkaç yasaklı yargıdan ardışık bağlantı gerektirir; bu, canlı SIM kartlarla ve iş seyahatleriyle gerçekçi değildir, ancak proxy ile her ülke için 10-15 dakika sürer.
Bu senaryo için, yalnızca ülke değil, şehir düzeyinde kesin coğrafi bağlama sahip proxy'ler uygundur - lisansın ülke içindeki bir bölge ile sınırlı olduğu durumlarda "Almanya genel olarak" değil, belirli eyaletleri kontrol etmek önemlidir.
Senaryo 3: A/B ve ülkeler bazında aşamalı dağıtımlar
Özellik bayrakları ve aşamalı dağıtımlar neredeyse her zaman coğrafi konuma bağlı olarak ayarlanır: yeni özellik önce Kanada'da, bir hafta sonra Avustralya'da, sonra her yerde etkinleştirilir. QA ekibi fiziksel olarak tek bir ülkede bulunuyorsa, bayrak onlara ulaşana kadar yeni sürümü diğer bölgelerden önce göremez.
Özelliği küresel yayımdan önce test etmek için, coğrafi konumu ilk dalga dağıtımının ülkesine değiştirmek gerekir. Bu, proxy'lerin anti-detect tarayıcılar veya cihaz emülatörleri ile birlikte çözmeye çalıştığı en yaygın görevlerden biridir - gerekli ülkeye IP'yi değiştiriyoruz, uygulama oturumunu yeniden başlatıyoruz, diğer kullanıcılardan önce özelliği görüyoruz ve bayrak %100 kitleye ulaşmadan önce hataları bulabiliyoruz.
Önemli bir nokta: A/B testleri için, test döngüsü boyunca IP'nin sabit bir "ikametgahı" olmalıdır - oturum, istekler arasında ülkeler arasında sıçramamalıdır, aksi takdirde backend deney koşullarını karıştırır ve kontrol grubunu veya test grubunu gösterir.
Senaryo 4: Yerelleştirme ve bildirimler
Bildirim metni, gönderim zamanı ve hatta teslimatın kendisi genellikle cihazın coğrafi konumuna bağlıdır. Bazı ülkelerde bildirim sağlayıcıları (Firebase, APNs, yerel SMS geçitleri) gecikmelerle veya alternatif yollarla çalışır - Moskova ofisinden test ortamında mükemmel bir şekilde teslim edilen bir bildirim, Endonezya'daki bir kullanıcıya, yerel iletişim sağlayıcısı tarafından belirli bildirim sunucularının engellenmesi nedeniyle ulaşmayabilir.
Ayrıca, arayüzün yerelleştirilmesi genellikle yalnızca sistem diline değil, IP'ye göre tetiklenir: Fransız IP'sine sahip bir telefonla İngilizce dilinde olan bir kullanıcı, Fransızca başlıklar ve İngilizce butonlar içeren karışık bir arayüz görebilir. Bu tür hatalar, tüm QA'nın tek bir coğrafi bölgeden test etmesi durumunda %100 görünmezdir.
Önerilen süreç: ürünün öncelikli pazarlarından 5-7 yerel alıyoruz, uygun IP ile proxy üzerinden bağlanıyoruz, cihaz/emülatörde sistem dilini değiştiriyoruz ve uygulamanın hangi metni ve tarih/sayı formatını gösterdiğini kaydediyoruz. IP ülkesi ve sistem dili arasındaki uyumsuzluk - ayrı bir zorunlu durumdur, genellikle unutulur.
Senaryo 5: Ödeme yöntemleri ve dolandırıcılık sistemleri
Mobil uygulamadaki mevcut ödeme yöntemleri genellikle ülkeye bağlıdır: bir bölgede kartla ödeme ve Apple Pay mevcutken, diğerinde yalnızca yerel cüzdanlar (Mercado Pago, Boleto, UPI, QIWI) ve üçüncüsünde iletişim operatörü aracılığıyla ödeme yapılabilir. QA, gerekli ülkeden bağlanamazsa, ödeme senaryolarının yarısı üretime kadar kontrol edilmeden kalır; burada hata fiyatı kaybedilen gelir ve destek şikayetleridir.
Ayrı bir sorun, ödeme sağlayıcılarının dolandırıcılık sistemleridir. Bu sistemler, IP'ye göre işlem riskini değerlendirir: veri merkezinden gelen bir IP ile yapılan istek neredeyse kesinlikle reddedilecektir veya ek 3D-Secure kontrolü gerektirecektir, kart tamamen geçerli olsa bile. Bu, test sonuçlarını çarpıtır: QA, ödemede reddedilme görüyor ve geliştiricilere hata rapor ediyor, oysa sorun kodda değil, test IP'sinin dolandırıcılık puanlaması için şüpheli görünmesindedir.
Ödeme senaryoları için rezidans proxy'leri veya mobil proxy'ler kullanmak daha iyidir - bunlar gerçek bir kullanıcının trafiği gibi görünür ve dolandırıcılık sistemlerinin gereksiz tetiklenmelerini sağlamaz, bu da ödeme akışının davranışını daha doğru bir şekilde gösterir.
Senaryo 6: Operatörlerin mobil ağlarındaki davranış
Ofis Wi-Fi'sinde 200 Mbit/s hızla mükemmel çalışan bir uygulama, 3G/4G mobil ağda, istikrarsız bir bağlantı, operatör NAT proxy'si ve yüksek gecikme ile tamamen farklı davranabilir. İstek zaman aşımı, yeniden denemeler, video/ses kalitesinin düşmesi, çevrimdışı modun çalışması - bunların hepsinin mobil internet koşullarına yakın bir ortamda test edilmesi kritik öneme sahiptir, yalnızca ofis ağında değil.
Ek bir zorluk: bazı iletişim operatörleri kendi proxy'lerini ve CGNAT'ı uygular, bu da sunucunun kullanıcının gerçek IP'sini değil, aynı anda binlerce abonenin geçtiği operatörün ortak IP'sini görmesine neden olur. Bu, rate limiting ve IP'ye göre coğrafi konumu etkiler - uygulama, kullanıcının fiziksel olarak bulunduğundan farklı bir şehirde olduğunu "düşünebilir".
Bu tür bir davranışı yeniden oluşturmak için, gerekli ülkenin gerçek SIM kartları aracılığıyla internete çıkan mobil proxy'ler gereklidir - bu, normal veri merkezi IP'sinde elde edilemeyecek NAT, gecikme ve hızın doğru bir resmini verir.
Senaryo 7: Rate limiting ve bot koruması
Birçok mobil uygulamanın backend API'si, bir IP'den gelen istek sayısını sınırlar (rate limiting) ve captcha veya davranış analizi gibi bot koruması kullanır. QA ekibi, tek bir kurumsal IP ile otomatik testler yapıyorsa, bir süre sonra sunucu 429 hataları vermeye veya istekleri tamamen engellemeye başlar - ve testler, uygulamadaki bir hata nedeniyle değil, backend'in test trafiğini bir saldırı olarak algılaması nedeniyle başarısız olur.
Bu, kısa bir süre içinde yüzlerce benzer isteğin (kayıt, giriş, sepete ekleme) gerçekleştirilmesi gereken yük testleri ve regresyon testleri için özellikle geçerlidir. Farklı IP'ler arasında isteklerin dağıtılması, proxy havuzu aracılığıyla API'yi adil bir şekilde yüklemeye olanak tanır, dolandırıcılık korumasının tetiklenmesi nedeniyle sonuçların çarpıtılmasını önler.
Bu tür büyük otomatik testler için genellikle veri merkezi proxy'leri kullanmak daha avantajlıdır - büyük miktarda istek için daha hızlı ve daha ucuzdur, bu senaryoda coğrafi bağlama göre hız ve bağlantı istikrarı kadar kritik değildir.
QA için araçlar ve proxy ayarları
Emülatörlerde (Android Studio Emülatörü, Xcode Simülatörü) manuel QA için proxy, emülatörün ağ ayarları aracılığıyla ayarlanır: proxy sunucusunun IP'sini ve portunu, kimlik doğrulama kullanılıyorsa kullanıcı adı ve şifreyi belirtirsiniz. Gerçek cihazlar için benzer ayarlar, Wi-Fi bağlantısında "Gelişmiş Ayarlar → Proxy → Manuel" üzerinden mevcuttur.
Uygulama ile backend arasındaki trafiği yakalamak ve analiz etmek için QA mühendisleri Charles Proxy veya Proxyman kullanır - her iki araç da uygulama trafiğini dış proxy üzerinden geçirmeye ve aynı anda tüm HTTP/HTTPS isteklerini, coğrafi konum başlıklarını ve sunucu yanıtlarını görmeye olanak tanır. Bu, tanı koyma için kullanışlıdır: backend'in isteği anında hangi IP'yi ve hangi ülkeyi "gördüğünü" hemen görmek mümkündür.
Appium veya Espresso aracılığıyla otomatik testler için proxy, oturumun istenen yeteneklerinde veya test seti başlatılmadan önce cihazın sistem ayarları aracılığıyla belirtilir. Mobil uygulama testleri için bulut platformları (BrowserStack, Sauce Labs) ayrıca özel proxy bağlantılarını destekler, bu da dünya genelindeki her noktada fiziksel cihazlar olmadan aynı otomatik test senaryosunu farklı ülkelerden çalıştırmaya olanak tanır.
Eğer ekipte uygulamanın web versiyonu varsa veya farklı coğrafi konumlarla birkaç hesabı paralel olarak test etmek gerekiyorsa, anti-detect tarayıcıları (Dolphin Anty, AdsPower, Multilogin) kullanmak uygundur - her profil ayrı bir proxy ile ilişkilendirilir ve QA mühendisi, aynı anda farklı ülkelerden 5-10 oturumu açık tutabilir, çerezler ve önbellek karışıklığı olmadan.
Her senaryo için hangi proxy türünü seçmeli
| QA Senaryosu | Önerilen Proxy Türü | Neden |
|---|---|---|
| Coğrafi fiyatlar ve içerik | Rezidans | Normal bir kullanıcının trafiği gibi görünür, bot korumasını tetiklemez |
| Coğrafi engellemeler | Rezidans | Şehir/bölge düzeyinde kesin coğrafi bağlama |
| A/B ve dağıtımlar | Rezidans / veri merkezi | Test döngüsü boyunca istikrarlı oturum |
| Bildirimler ve yerelleştirme | Mobil | Operatörler aracılığıyla teslimatın gerçek koşullarını simüle eder |
| Ödemeler ve dolandırıcılık | Rezidans / mobil | Dolandırıcılık sistemlerinin yanlış tetiklenme riskini azaltır |
| Mobil operatör ağları | Mobil | Operatörlerin gerçek SIM kartları, NAT ve gecikmelerin kesin simülasyonu |
| Rate limiting / yük testleri | Veri merkezi | Büyük miktarda istek için yüksek hız ve düşük maliyet |
Yayımdan önce kontrol listesi
Derlemeyi üretime göndermeden önce, coğrafi konum ve ağ ile ilgili kısa bir kontrol listesine göz atın - bu, yukarıda belirtilen hataların çoğunu kapatır:
- Ürünün en az 5 ana pazarında abonelik fiyatları ve para birimi kontrol edildi
- Yasaklı ülkelerde coğrafi engelleme ekranının doğru görüntülenmesi kontrol edildi
- Özellik bayrağı, küresel yayımdan önce ilk dalga dağıtımında test edildi
- Bildirimler, farklı ülke kombinasyonlarından IP ve sistem dili ile kontrol edildi
- Her ana bölge için mevcut ödeme yöntemleri ayrı ayrı kontrol edildi
- Ödeme akışı, dolandırıcılık sistemlerinin yanlış tetiklenmesi olmadan test edildi
- Uygulama, yalnızca Wi-Fi değil, mobil ağ koşullarında (3G/4G) test edildi
- Otomatik testler, bir IP'den paralel başlatıldığında rate limiting nedeniyle başarısız olmuyor
Sonuç
Mobil uygulama, aynı anda onlarca ülkede, ağda ve ödeme ekosisteminde yaşarken, QA ekibi fiziksel olarak tek bir ofiste tek bir IP ile oturuyor. Gerçek kitle ile test koşulları arasındaki bu kopukluk, üretime ulaşan çoğu "açıklanamayan" hatayı doğurur. Yukarıdaki yedi senaryo - coğrafi fiyatlar, coğrafi engellemeler, A/B dağıtımları, bildirimler ve yerelleştirme, ödemeler, operatörlerin mobil ağları ve rate limiting - bu tür risklerin büyük bir kısmını kapatır.
Eğer ekibiniz, bölgesel içerik, fiyatlar veya ödemelerle çalışan bir uygulamayı test ediyorsa, gerçek kullanıcıları simüle etmek için test yığınınıza rezidans proxy'leri eklemek mantıklıdır, mobil bağlantı ve bildirim teslim senaryoları için ise belirli operatörlere bağlanan mobil proxy'ler kullanmak mantıklıdır. Bu, kritik hataları QA aşamasında bulmayı sağlar, kullanıcıların mağazalarda şikayet etmesinden önce.