QA Testçisi için Proxy: 20 Ülkeden Web Uygulamasını Seyahatsız Nasıl Test Edilir

Yeni bir sürüm çıkardınız ve bir saat içinde bir hata raporu geliyor: “Almanya'da sayfanın yanlış versiyonu gösteriliyor”, “ABD'de ödeme çalışmıyor”, “Rusya'da içerik engellendi”. Bunu yerel makineden yeniden oluşturmak — imkansız. İşte burada proxy, “arbitrajcıların aracı” olmaktan çıkıp QA mühendisinin tam anlamıyla işlevsel bir aracı haline geliyor.

Bu yazıda, coğrafi olarak bağımlı uygulama davranışlarını test etmek için proxy'lerin nasıl doğru bir şekilde kullanılacağını, farklı QA görevleri için hangi proxy türlerinin uygun olduğunu ve coğrafi içerik kontrolünden ödeme geçitlerinin testine kadar adım adım senaryoları göstereceğiz.

QA test uzmanı için proxy: gerçek senaryolar

Birçok ekip hala uygulamanın “uluslararası” davranışını yalnızca yerel makinelerden test ediyor ve ara sıra VPN kullanıyor. Bu, büyük bir kör nokta oluşturuyor. VPN IP adresini değiştiriyor, ancak belirli bir ülkeden kullanıcının gerçek ağını simüle etmiyor — sağlayıcı, bağlantı türü, mobil operatör. Proxy'ler ise, gerekli bölgeden veya ağ türünden gerçek bir IP adresi ile internete çıkma imkanı sunar.

İşte QA test uzmanlarının her gün karşılaştığı belirli görevler:

• Coğrafi içerik ve yerelleştirme. Uygulama, kullanıcının ülkesine bağlı olarak farklı içerikler gösterir: yerel para birimindeki fiyatlar, bölgesel kampanyalar, engellenmiş bölümler. Proxy olmadan bunu kontrol etmek imkansızdır.
• Bölgesel ödeme sistemleri. Stripe, AB ve ABD'de farklı çalışır. Brezilya'daki PayPal — ayrı bir durum. Ödeme akışını tam olarak gerekli ülkeden test etmek gerekir.
• CDN ve önbellekleme. İçerik dağıtım ağı, farklı noktalardan farklı versiyonlar sunabilir. QA, statik içeriğin Asya, Avrupa ve Amerika'daki kullanıcılar için doğru bir şekilde yüklendiğinden emin olmalıdır.
• Engellemeler ve kısıtlamalar. Bazı ülkelerde uygulamanın bazı işlevleri yasal olarak kullanılamaz. Engellemenin doğru çalıştığından ve kullanıcının anlaşılır bir mesaj gördüğünden emin olunmalıdır.
• A/B testleri coğrafi olarak. Eğer deney yalnızca Birleşik Krallık'taki kullanıcılara yönelik başlatıldıysa, QA'nın Birleşik Krallık IP'si ile giriş yapması ve gerekli seçeneği gördüğünden emin olması gerekir.
• SEO testleri. Meta etiketleri, hreflang, bölgesel sayfa versiyonları — bunların hepsi ilgili ülkeden bir IP ile kontrol edilmelidir, aksi takdirde arama motoru ve gerçek kullanıcı farklı şeyler görecektir.
• Farklı bölgelerden hız testi. Singapur'dan ve Moskova'dan sayfanın yüklenme süresi 3-5 kat farklı olabilir. Proxy'ler bunu tek bir çalışma alanında yeniden oluşturmayı sağlar.

Hangi proxy türleri test için uygundur

Tüm proxy'ler QA için aynı derecede yararlı değildir. Hangi türü seçeceğiniz, tam olarak neyi test ettiğinize bağlıdır. Üç ana türü ve test uzmanının görevleri için uygulanabilirliğini inceleyelim.

Konut Proxy'leri

Bu, belirli ülkelerden ve şehirlerden gerçek ev kullanıcılarının IP adresleridir. Site, onları normal insanlar olarak görür, veri merkezi veya kurumsal ağ olarak değil. Konut proxy'leri, çoğu QA görevleri için en uygun seçimdir: coğrafi içerik testleri, A/B testleri, ödeme akışları ve yerelleştirme kontrolü. Gerekli ülkeden gerçek bir kullanıcıyı en doğru şekilde simüle ederler.

QA için avantajları: siteler ve uygulamalar tarafından yüksek güven, geniş coğrafi kapsama (100+ ülke), belirli bir şehir veya sağlayıcıyı seçme imkanı. Dezavantajı — veri merkezi proxy'lerine göre biraz daha yavaş olmalarıdır, bu da performans testlerinde dikkate alınmalıdır.

Mobil Proxy'ler

Mobil operatörlerin IP adresleri (3G/4G/5G). Mobil kullanıcılar için uygulamanın davranışını test ederken kritik öneme sahiptir. Birçok site ve uygulama, mobil IP ile giriş yapıldığında farklı davranır: mobil versiyonu gösterir, farklı içerikler sunar, coğrafi konumu farklı işler. Mobil proxy'ler, mobil uygulamaların emülatörler aracılığıyla test edilmesinde veya web versiyonunun uyumluluğunun kontrol edilmesinde vazgeçilmezdir.

Ayrıca, mobil IP'ler dinamik adreslerdir ve bir operatör, bunları binlerce aboneye dağıtır. Bu, test trafiğinizin yoğun taleplerle bile şüpheli görünmemesini sağlar.

Veri Merkezi Proxy'leri

En hızlı ve en ucuz olanlardır. Yük testleri, büyük miktarda istekle otomatik testler, API uç noktalarının kontrolü için uygundur. Veri merkezi proxy'leri, “ev kullanıcıları” olarak kolayca tespit edilir, bu nedenle kullanıcı deneyimini test etmek için daha az uygundur — ancak teknik kontroller ve yük için en uygun seçimdir.

Coğrafi içerik test etme: adım adım

Coğrafi test etme, QA'da proxy kullanımının en yaygın senaryosudur. İşte bunun pratikte nasıl yapıldığı, kod yazmadan, sıradan bir tarayıcı aracılığıyla.

Adım 1. Proxy verilerini alın

Servise bağlandıktan sonra, bağlantı için verileri alırsınız: host (IP veya alan adı), port, kullanıcı adı ve şifre. Konut proxy'leri için genellikle kişisel panelde veya bağlantı dizesindeki parametreler aracılığıyla ülke ve şehir seçebilirsiniz.

Konut proxy'si için ülke seçimi ile bağlantı dizesinin örneği şöyle görünür: host, ülke parametresini içerir (örneğin, country-de Almanya için), port — standart, kullanıcı adı ve şifre — sizin kimlik bilgilerinizdir.

Adım 2. Tarayıcıda proxy'yi ayarlayın

Manuel test için en uygun olan, sistem ayarlarını değiştirmeden proxy'yi hızlı bir şekilde değiştirmeye olanak tanıyan tarayıcı uzantılarıdır. Popüler seçenekler: Proxy SwitchyOmega (Chrome/Firefox), FoxyProxy (Firefox).

Proxy SwitchyOmega ile adım adım ayarlama:

1. Chrome Web Store'dan uzantıyı yükleyin.
2. Uzantı ayarlarını açın → “Yeni Profil”e tıklayın → “Proxy Profili”ni seçin.
3. Proxy verilerini girin: Protokol (SOCKS5 veya HTTP), Sunucu (host), Port (port).
4. Kimlik doğrulama gerekiyorsa — kullanıcı adı ve şifreyi ilgili alanlara girin.
5. Profili kaydedin ve tarayıcı panelindeki uzantı simgesinden etkinleştirin.
6. whatismyip.com veya 2ip.ru sitesine gidin — gerekli ülkeden IP'nin göründüğünden emin olun.

Adım 3. Coğrafi bağımlı öğeleri kontrol edin

Gerekli coğrafi proxy ile bağlandıktan sonra kontrol edin:

• Arayüz dili (IP'ye göre otomatik belirleme)
• Fiyatların para birimi ve ödeme yöntemleri
• Belirli web bölümlerinin varlığı/yokluğu
• Belirli bir bölge için bannerlar ve kampanyalar
• hreflang etiketlerinin doğruluğu (sayfanın kaynak kodunu açın)
• Bölgesel alt alan adlarına yönlendirmeler (örneğin, de.site.com yerine site.com)
• Çerez bannerları (AB'de GDPR gereği zorunludur)

Farklı ağ türlerinden test etme

Coğrafyanın yanı sıra, uygulamanın kullanıcı ağ türüne bağlı olarak davranışını test etmek de önemlidir. Bu, küresel bir kitleye sahip ürünler için özellikle kritik öneme sahiptir; burada kullanıcıların önemli bir kısmı mobil cihazlar üzerinden operatör ağlarıyla giriş yapmaktadır.

Kurumsal ağlar ve güvenlik duvarları

Kurumsal ağlardan gelen kullanıcılar genellikle şirketin proxy sunucuları ve güvenlik duvarları aracılığıyla çalışır ve belirli türde istekleri, WebSocket bağlantılarını veya harici CDN'leri engeller. Bu tür koşulları simüle etmek için test uzmanları, sınırlı ayarlarla veri merkezi proxy'lerini kullanır — bu, “sert” kurumsal ortamı yeniden oluşturmayı sağlar.

Bu senaryoda kontrol edilecekler: push bildirimleri çalışıyor mu, Google Fonts'tan fontlar yükleniyor mu (genellikle kurumsal güvenlik duvarları tarafından engellenir), OAuth ile kimlik doğrulama doğru çalışıyor mu.

Mobil ağlar (3G/4G/5G)

Mobil proxy aracılığıyla test uzmanı, yalnızca mobil IP almakla kalmaz, aynı zamanda mobil ağın gerçek koşullarını da elde eder: farklı gecikmeler, NAT özellikleri, mobil operatörlerden gelen spesifik istek başlıkları. Bazı uygulamalar, mobil IP'lerden gelen istekleri farklı işler — örneğin, web versiyonunu göstermek yerine uygulamayı indirmeyi önerir.

Mobil proxy'leri, Chrome DevTools'daki cihaz emülatörü ile birleştirerek (Cihaz Araç Çubuğu modu) — böylece gerçek bir kullanıcı ortamına en yakın deneyimi elde edersiniz.

Sınırlı erişime sahip sağlayıcılar

Bazı ülkelerde internet sağlayıcıları belirli kaynakları engeller veya rakiplere giden trafiği yavaşlatır. Ürününüz sınırlı internetin olduğu pazarlarda (Çin, İran, Rusya) çalışıyorsa, bu ülkelerden konut proxy'leri aracılığıyla test yapmak, hizmetin erişilebilirliğini gerçek bir şekilde gösterecektir.

Ödeme geçitleri ve bölgesel işlevlerin test edilmesi

Ödeme testi, uluslararası ürünlerde QA için en acı veren alanlardan biridir. Ödeme sistemleri, dolandırıcılık kontrolü için coğrafi konumu aktif olarak kullanır: Eğer kullanıcının IP'si, ödeme adresi veya kartın ülkesi ile uyuşmuyorsa, işlem reddedilebilir veya şüpheli olarak işaretlenebilir.

QA test uzmanı, tam olarak bu senaryoyu yeniden oluşturmalıdır: test kartının verildiği ülkeden bir IP ile giriş yapmalı ve tüm ödeme akışını geçmelidir. Proxy olmadan bunu tek bir makineden birkaç bölge için yapmak imkansızdır.

Ödeme testinde proxy ile neyi kontrol etmelisiniz

• Bölgeye uygun ödeme yöntemlerinin görünürlüğü (PayPal, Stripe, Klarna, SEPA, PIX — her bölgenin kendine özgü yöntemleri vardır)
• Para birimi dönüşümünün ve komisyonların doğruluğu
• Farklı ülkelerden 3DS doğrulamasının çalışması
• IP ve kartın ülkesi uyuşmadığında davranış (doğru hata mesajının görünmesi gerekir)
• Bölgesel vergiler (AB'de KDV, Avustralya'da GST) — doğru hesaplanıyor mu
• Bölgesel ödeme yöntemlerinin çalışması: Hollanda'da iDEAL, Almanya'da Sofort, Brezilya'da Boleto

Bölgesel işlevlerin test edilmesi (GDPR, CCPA ve diğerleri)

Ürünlere yönelik yasal gereklilikler, kullanıcının ülkesine bağlı olarak değişir. QA için, uygulamanın yargı yetkisini doğru bir şekilde belirlediğinden ve gerekli kuralları uyguladığından emin olmak önemlidir:

• AB (GDPR): Avrupa IP'sinden giriş yapıldığında, izleme reddetme seçeneği ile çerez bannerı görünmelidir
• Kalıforniya (CCPA): “Kişisel Bilgilerimi Satmayın” bağlantısı, Kaliforniya'dan gelen kullanıcılar için görünmelidir
• Rusya: Rus kullanıcıların verileri Rusya'daki sunucularda saklanması gerekiyorsa — yerelleştirmenin doğru çalıştığını kontrol edin
• Çin: Çin IP'sinden giriş yapıldığında harici hizmetlerin (Google Analytics, Facebook Pixel) engellenip engellenmediğini ve bunun sayfayı bozup bozmadığını kontrol edin

Proxy desteği olan QA araçları

Proxy'leri yalnızca tarayıcıda manuel olarak değil, aynı zamanda otomatik testler ve QA araçlarına entegre etmek için de kullanabilirsiniz. Temel seçenekleri inceleyelim.

Postman

Proxy aracılığıyla API test etmek için Postman'da: Ayarlar → Proxy → Sistem Proxy'sini Kullan'ı etkinleştirin veya proxy'yi manuel olarak belirtin. Bu, API uç noktalarının farklı ülkelerden gelen isteklere nasıl yanıt verdiğini kontrol etmenizi sağlar — coğrafi olarak bağımlı API'ler için geçerlidir, bu API'ler IP'ye bağlı olarak farklı içerikler döndürür.

Charles Proxy / Fiddler

Bu araçlar, HTTP/HTTPS trafiğini yakalar ve kendileri proxy'dir. Trafiği harici bir proxy sunucusundan (upstream proxy) geçecek şekilde ayarlayabilirsiniz. Bu, istekleri aynı anda yakalamak ve analiz etmek ve gerekli coğrafi IP ile test etmek için bir fırsat sunar.

Charles'ta: Proxy → Harici Proxy Ayarları → Harici proxy kullan'ı etkinleştirin ve proxy sunucunuzun verilerini belirtin.

Playwright ve Selenium

Otomatik testler için proxy, tarayıcı yapılandırma seviyesinde bağlanır. Playwright'ta, tarayıcı bağlamı oluşturulurken proxy parametresi ile yapılır. Selenium'da ise, proxy sunucusunu belirterek ChromeDriver seçenekleri aracılığıyla yapılır. Bu, manuel ayar gerektirmeden, onlarca ülkeden test suitlerini paralel modda çalıştırmanıza olanak tanır.

BrowserStack ve Sauce Labs

Farklı bölgelerden test için bulut tabanlı platformlar, yerleşik araçlara sahiptir. Ancak, belirli bir sağlayıcı veya ağ türü (mobil/ev) seçme yetenekleri sınırlıdır. Proxy'ler daha fazla esneklik sağlar: ülkeyi, şehri, IP türünü ve sağlayıcıyı kendiniz seçersiniz.

k6 ve JMeter (yük testi)

Farklı bölgelerden yük testi için veri merkezi proxy'leri, HTTP istemcisi yapılandırması aracılığıyla bağlanır. Bu, farklı ülkelerden gerçek kullanıcıların yükünü simüle etmeyi ve CDN'lerin ve yük dengeleyicilerin coğrafi olarak dağıtılmış trafiği nasıl yönettiğini kontrol etmeyi sağlar.

Kontrol listesi: sürüm öncesi proxy ile kontrol edilecekler

Uluslararası bir kitleyi etkileyen her sürüm için bu kontrol listesini kullanın. Ürününüzün en az 3-5 ana bölgesini kontrol etmenizi öneririz.

Proxy ile test ederken sık yapılan hatalar

Deneyimli test uzmanları bile proxy ile çalışırken hatalar yapabilir. En yaygın olanları inceleyelim.

Hata 1: Proxy'nin gerçekten çalışıp çalışmadığını kontrol etmemek

Teste başlamadan önce, her zaman mevcut IP'yi bağımsız bir kaynakta kontrol edin (whatismyip.com, 2ip.ru, ipleak.net). Bazen proxy ayarlanmış olabilir, ancak tarayıcı hala doğrudan bağlantı kullanıyor olabilir — özellikle uzantı etkinleştirilmemişse veya sistem ayarlarıyla bir çakışma varsa.

Hata 2: DNS sızıntılarını görmezden gelmek

DNS istekleri proxy'yi atlayabilir ve test uzmanının gerçek IP'sini açığa çıkarabilir. Bu, coğrafi engellemeleri test ederken özellikle önemlidir — site, DNS üzerinden gerçek ülkeyi belirleyebilir, IP adresi değiştirilmiş olsa bile. DNS sızıntılarını ipleak.net veya dnsleaktest.com üzerinden kontrol edin.

Hata 3: Tüm görevler için tek bir proxy kullanmak

Veri merkezi proxy'si, kullanıcı deneyimini test etmek için uygun değildir — site, ona CAPTCHA veya gerçek bir kullanıcının asla görmeyeceği bir engellenmiş sayfa gösterebilir. Her görev için doğru proxy türünü kullanın (yukarıdaki tabloya bakın).

Hata 4: Tarayıcı önbelleğini unutmamak

Coğrafi konumlar arasında geçiş yaparken, tarayıcı önceki oturumdan önbelleğe alınmış içeriği verebilir. Her zaman yeni bir proxy'ye geçmeden önce önbelleği ve çerezleri temizleyin veya her yeni coğrafi test için gizli mod kullanın.

Hata 5: Test oturumlarını belgelememek

Proxy aracılığıyla bir hata bulunduğunda, mutlaka kaydedin: proxy'nin ülkesini ve şehrini, proxy türünü (konut/mobil), test zamanını, tarayıcı sürümünü. Bu veriler olmadan, geliştiricinin sorunu yeniden oluşturması zor olacaktır. Hata raporuna IP'yi doğrulayan bir ekran görüntüsü ekleyin.

Hata 6: Dokümantasyonda proxy ve VPN'i karıştırmak

Ekiplerde sıkça hata raporlarında “Almanya'dan VPN aracılığıyla yeniden oluşturuldu” yazıyorlar — ancak VPN ve proxy farklı çalışır. VPN tüm trafiği şifreler ve IP'yi işletim sistemi düzeyinde değiştirir, proxy ise uygulama düzeyinde çalışır. Bazı hatalar için bu temel bir farktır. Dokümantasyonda kesin ifadeler kullanın.

Sonuç

QA test uzmanı için proxy, uluslararası bir kitleye sahip herhangi bir ürün için temel bir araçtır. Farklı ülkelerden kullanıcıların gerçek koşullarını yeniden oluşturmayı, coğrafi bağımlı içeriği, ödeme geçitlerini, yasal gereklilikleri ve CDN davranışını kontrol etmeyi sağlar — tüm bunları çalışma alanından, iş seyahatleri ve uzaktan makineler olmadan.

Ana çıkarımlar: kullanıcı deneyimini test etmek için konut proxy'leri kullanın, mobil senaryolar için mobil proxy'ler, yük ve API testleri için veri merkezi proxy'leri uygundur. Teste başlamadan önce IP'yi her zaman kontrol edin, DNS sızıntılarına dikkat edin ve test oturumlarını coğrafi parametreleri belirterek belgeleyin.

Uygulamanızın coğrafi bağımlı davranışını test etmeye başlamak istiyorsanız, konut proxy'lerini denemenizi öneririz — bunlar, gerekli ülkeden gerçek bir kullanıcıyı en doğru şekilde yeniden oluşturmayı sağlar ve şehir ve sağlayıcıya kadar esnek coğrafi seçim desteği sunar.