Uygulama Testi için Rotating Proxy

Geo QA’ye yeni başlayan ekiplerde sık görülen bir beklenti var: proxy bağlandığı anda uygulamanın kendini Almanya’da ya da Brezilya’da sanacağı düşünülür. Oysa proxy ağ katmanında tek bir şeyi değiştirir: sunucunuzun gördüğü çıkış adresini. Bu adresle birlikte IP’nin hangi ülkeye eşlendiği, hangi ağ türüne (veri merkezi, konut, mobil operatör) ait olduğu ve IPv4 mü IPv6 mı olduğu değişir. Uygulamanız ise lokasyon kararını çoğu zaman tek bir sinyalden vermez; cihaz dili, saat dilimi, GPS izni, SIM operatörü, uygulama mağazası hesabının ülkesi, profildeki adres ve önceki ziyaretten kalan çerez de hesaba girer.

Bu yüzden rotating proxy bir “ülke değiştirme düğmesi” değil, test ortamının ağ katmanını kontrol etmenin yoludur. Hangi kararın hangi sinyale dayandığını bilmeden kurulan bir test, yanlış sinyal sayesinde “geçti” sonucu verebilir: Almanya çıkışlı bir koşuda fiyatın euro görünmesi belki yalnız tarayıcı dilinin de-DE olmasından kaynaklanır ve IP tabanlı kural aslında hiç çalışmamıştır. Aşağıdaki tablo, geo QA’de rol oynayan sinyalleri ve her birinin nasıl ayarlandığını özetler.

Tablodan çıkan pratik kural şudur: proxy’yi test profilinin yalnız bir parçası olarak düşünün. Bir profil “ülke + ağ türü + dil + saat dilimi + hesap” birleşimidir ve bu birleşimin tutarlı olması gerekir. Tutarsız profiller de bilerek seçildiğinde değerlidir: Almanya’dan bağlanan ama cihaz dili Türkçe olan kullanıcı gerçek bir kitledir ve uygulamanızın dil ile ülke çeliştiğinde ne yaptığı ayrı bir test vakasıdır. Önemli olan, çelişkinin kazara değil plan gereği oluşmasıdır.

Proxy paketine bakmadan önce uygulamanızın lokasyona göre nerede karar verdiğini listeleyin. Bu liste test planının omurgasıdır ve çoğu ekipte dağınık hâlde durur: bir kısmı istemci kodunda, bir kısmı sunucudaki yerelleştirme katmanında, bir kısmı CDN ve WAF kurallarında, bir kısmı da ödeme sağlayıcısının panelinde. Kod tabanında ülke, bölge, locale, para birimi ve IP sorgusu geçen yerleri aramak, feature flag kurallarını ve edge yapılandırmasını gözden geçirmek iyi bir başlangıçtır. Tipik bir envanter şu başlıklardan oluşur:

• Yönlendirme: kök adresin ülke alt yoluna ya da bölgesel alan adına gönderilmesi, dil seçicinin varsayılan değeri, desteklenmeyen ülkeler için gösterilen sayfa.
• Fiyat ve para birimi: gösterilen para birimi, vergi dahil veya hariç gösterim, yuvarlama kuralı, bölgesel kampanya fiyatı.
• Ödeme: listelenen ödeme yöntemleri, taksit seçenekleri, ödeme sağlayıcısının bölgeye göre açtığı ek doğrulama adımı.
• Yasal metinler ve onaylar: çerez onay bandının hangi ülkelerde ve hangi sırada gösterildiği, sözleşme sürümü, yaş doğrulama ekranı.
• İçerik ve katalog: lisans veya mevzuat nedeniyle bölgeye göre gizlenen ürün ve içerikler, bölgesel banner ve duyurular.
• Kayıt ve giriş: telefon alanındaki varsayılan ülke kodu, SMS doğrulama akışı, desteklenmeyen bölgeden kayıt denemesinde gösterilen mesaj.
• Özellik bayrakları: ülke kuralıyla açılan özellikler ve kademeli yayınlardaki ülke bazlı yüzdeler.
• Güvenlik kuralları: risk motorunun ve WAF’ın veri merkezi, konut ve mobil operatör adreslerine verdiği farklı tepkiler, IP başına hız sınırları.
• Altyapı: CDN’in seçtiği edge, bölgesel API uç noktası, veri yerleşimi kuralları gereği isteğin hangi bölgede işlendiği.

Her maddenin yanına iki şey yazın: kararı veren sinyal ve beklenen davranış. “Ödeme ekranı Almanya’dan gelen kullanıcıya banka havalesini gösterir; karar IP ülkesine ve hesap adresine göre verilir” gibi bir cümle, test vakasının hem girdisini hem doğrulama ölçütünü tanımlar. Beklenen davranış yazılmamışsa test sonucu yoruma dönüşür; aynı ekran görüntüsüne bakan iki kişi farklı sonuç çıkarır.

Envanter proxy ihtiyacını da küçültür. Yalnız cihaz diline bakan bir dil seçimini test etmek için kota harcamanıza gerek yoktur; emülatörün dil ayarı yeter. Envanteri “kararı veren sinyal” sütununa göre sıraladığınızda hangi satırların gerçekten proxy gerektirdiği kendiliğinden ortaya çıkar: IP ülkesine, ağ türüne veya IP sürümüne dayanan kararlar. Geri kalanlar proxy olmadan, daha hızlı ve ücretsiz test edilir.

Geo QA genellikle yalnız ülke ekseninde düşünülür, oysa sunucunuz aynı ülkeden gelen iki isteği ağ türüne göre farklı karşılayabilir. Risk motorları, WAF kuralları ve bazı ödeme sağlayıcıları IP’nin ait olduğu ağın (ASN) türünü bir sinyal olarak kullanır. Bu yüzden ağ türü test matrisinde ülke kadar önemli bir eksendir. RotatingProxy kataloğundaki beş ürün bu ekseni karşılar; hepsi HTTP, HTTPS ve SOCKS5 ile kullanılır. Tabloda her birinin QA’de hangi soruyu yanıtladığı görülür.

Mobile ürünüyle ilgili sık yapılan bir yorum hatası var: taşıyıcı ağ IP’si üzerinden çıkmak, cihazın hücresel ağda olduğu anlamına gelmez. Test cihazı Wi-Fi’a bağlıyken trafiğini mobile proxy’den geçirirseniz sunucu operatör adresi görür, ama uygulamanın kendi ağ durumu sorgusu hâlâ Wi-Fi döner. “Hücresel ağda büyük medya otomatik indirilmesin” gibi istemci tarafı kurallar bu yöntemle test edilmez; onlar için SIM’li gerçek cihaz veya emülatörün ağ ayarı gerekir. Mobile proxy’nin asıl test ettiği şey, sunucu tarafının operatör adresine verdiği tepkidir.

Bu tepkinin önemli bir boyutu adres paylaşımıdır. Mobil operatörler çoğu zaman taşıyıcı sınıfı NAT kullanır ve aynı genel IP arkasında çok sayıda abone bulunabilir. IP başına sıkı bir hız sınırı ya da “bu IP’den kısa sürede çok kayıt geldi” kuralı, masaüstünde sorunsuz görünürken operatör ağındaki meşru kullanıcıları kesebilir. Bu eşikleri staging ortamında, düşük hacimle ve birkaç test hesabıyla gözlemlemek, sürümden sonra destek kuyruğunda öğrenmekten çok daha ucuzdur.

IPv6 ekseni çoğu QA planında hiç yer almaz ve hatalar da genellikle burada saklanır. Alan adınızda AAAA kaydı olduğu hâlde IPv6 uç noktasının farklı bir yapılandırmayla çalışması, veritabanındaki IP kolonunun IPv4 uzunluğuna göre tanımlanmış olması, hız sınırlayıcının her tekil IPv6 adresini ayrı kullanıcı sayması (tek bir abone /64 gibi geniş bir bloğa sahip olabilir) ya da geo veritabanınızın IPv6 aralıklarını daha zayıf eşlemesi tipik örneklerdir. 2001:db8:: önekiyle yazılmış birim testleri bu sorunları yakalamaz; gerçek bir IPv6 çıkışından gelen istek yakalar. IPv6 ürünleri port bazlı aylık faturalandığı için sürekli değil, IPv6 hazırlık testinin yapıldığı dönemde kullanmak mantıklıdır.

Bütün eksenleri çarptığınızda sayı hızla yönetilemez hâle gelir. Kapsamı katalogdan hesaplayalım: öne çıkan 15 ülke yalnız üç IPv4 ağında (Datacenter, Residential, Mobile) 45 ülke-ağ çifti eder; IPv6 Datacenter’ın 8 ve IPv6 Residential’ın 9 doğrulanmış ülkesi 17 çift daha ekler. Toplam 62 çifti dört istemciyle (Android uygulaması, iOS uygulaması, masaüstü web, mobil web) çarpmak 248 hücre, her hücrede on senaryo koşarsanız bir tur 2.480 test koşusu demektir (15 ülkeyi beş ağın hepsinde varsaymak 300 hücrelik yanıltıcı bir üst sınır verirdi; IPv6 kapsamı daha dardır). Bunu her sürümde çalıştırmak ne süre ne de kota açısından savunulabilir. Amaç her kombinasyonu denemek değil, riskli kombinasyonları her turda, geri kalanları dönüşümlü olarak görmektir. Daraltma için beş ilke yeterlidir:

• Ülkeleri davranış grubuna göre kümeleyin: aynı para birimini, aynı yasal metni ve aynı ödeme sağlayıcısını paylaşan pazarlardan biri grubun temsilcisi olur; temsilci her turda, diğerleri dönüşümlü koşar.
• Ağ türünü senaryoya bağlayın: kullanıcı yolculuğu residential veya mobile ile, güvenlik kuralı kontrolü datacenter ile, IPv6 hazırlığı IPv6 ürünleriyle test edilir.
• İstemciyi değişikliğe bağlayın: değişiklik yalnız sunucu tarafındaki bir kuralı etkiliyorsa tek istemci yeter; istemci kodunda yerelleştirme değiştiyse her platform ayrı koşar.
• Kapsamayı tur boyunca dağıtın: çekirdek matris her ülkeyi, ağ türünü ve istemciyi en az bir kez görür; ülke-ağ ve ağ-istemci çiftlerinin tamamı (ikili kapsama) dönüşümlü turlarla ve çeyreklik tam koşuda tamamlanır; üçlü kombinasyonların tamamı gerekmez.
• Riskle ağırlıklandırın: gelirde payı yüksek pazarlar, yeni açılan pazarlar ve son sürümde hata çıkan pazarlar her turda yer alır.

Bu altı hücre; altı ülkeyi, dört ağ türünü ve beş istemci tipini (Android, iOS, masaüstü web, mobil web ve API istemcisi) en az bir kez görür; yani her değeri bir kez görür, her çifti değil. Sürüm başına koşulan bu çekirdek matrisin yanında tam matris çeyrek dönemde bir kez ya da büyük bir yerelleştirme değişikliğinden önce koşulabilir. Matrisi bir tablo dosyasında veya test yönetim aracında tutmak, hangi hücrenin en son ne zaman koştuğunu görünür kılar ve dönüşümlü planlamayı kolaylaştırır.

Katalogda rotasyon davranışı ürün ailesine göre farklı tanımlanır: IPv4 Datacenter’da istek başına veya oturum bazlı rotasyon, IPv4 Residential ve Mobile’da sticky ve rotating oturum seçenekleri, IPv6 ürünlerinde oturum yapılandırmalı rotasyon. Sticky oturumun aynı IP’yi ne kadar süre koruduğu ve oturumun hangi parametreyle seçildiği gibi ayrıntıları panelde ve sipariş adımında kontrol edin; test yapılandırmasına da oradaki sözdizimini taşıyın.

Rotasyonun QA açısından önemi şudur: modern uygulamaların çoğu oturumu bir ölçüde IP ile ilişkilendirir. Oturum belirteci IP değiştiğinde şüpheli sayılabilir, risk motoru yeni adreste ek doğrulama isteyebilir, ödeme sağlayıcısı ödeme adımında sepet adımından farklı bir IP görebilir. Giriş, sepet ve ödeme gibi çok adımlı bir akış her istekte farklı IP’den koşarsa test kırmızıya döner; ama bu durumda hata çoğu zaman ürünün değil test kurulumunundur.

Basit bir kural iş görür. Çok adımlı ve durum taşıyan akışlar (giriş, sepet, ödeme, profil düzenleme, uygulama içi satın alma) sticky oturumla koşar. Tek istekte biten ve durum taşımayan kontroller (yönlendirme hedefi, para birimi, yanıt başlıkları, API’nin ülkeye göre döndürdüğü alanlar) rotating oturumla (IPv4 Datacenter’da istek başına rotasyonla) koşar. İkinci grupta rotasyon bir avantajdır: aynı ülkenin farklı adreslerinden örnek alırsınız ve tek bir IP’nin geo veritabanında yanlış eşlenmesi tüm sonucu bozmaz. Tarayıcıyla açılan bir sayfa onlarca alt istekten oluştuğu için tarayıcı tabanlı testlerde sticky oturum genellikle daha öngörülebilir sonuç verir.

Aynı mantık operatör adresi paylaşımı için de kullanılabilir. Tek bir sticky mobile çıkışından birkaç sentetik test hesabıyla sırayla giriş yapmak, IP başına uyguladığınız eşiklerin aynı NAT arkasındaki meşru kullanıcıları ne zaman etkilemeye başladığını gösterir. Bunu yalnız kendi staging ortamınızda, düşük hacimle ve güvenlik ekibinin bilgisi dahilinde yapın; amaç eşiği ölçmek, sistemi yormak değildir.

Geo testlerini birim ve entegrasyon testleriyle aynı işte koşmak iki nedenle kötü bir fikirdir: her çekme isteğinde kota harcar ve proxy kaynaklı bir zaman aşımı ilgisiz bir kod değişikliğini kırmızıya boyar. Daha sağlıklı düzen, geo testlerini ayrı bir iş olarak tanımlamaktır. Tetikleyici olarak gece koşusu, sürüm dalına birleştirme ve lokasyon kararlarına dokunan dosyalardaki değişiklik (yerelleştirme kaynakları, fiyat ve ödeme yapılandırması, feature flag kuralları, edge yapılandırması) yeterlidir. Bu işin kurulumunda şu ilkeler işe yarar:

• Kimlik bilgileri CI’ın gizli değişken deposunda tutulur ve iş çıktısında maskelenir; kullanıcı adı ve şifre içeren proxy adresi hiçbir log satırına yazılmaz.
• Proxy’nin kapsamı daraltılır: runner’ın tamamına HTTPS_PROXY vermek yerine proxy yalnız test adımında ya da tarayıcı bağlamında tanımlanır. Global tanım zorunluysa paket kayıtları, iç servisler ve artifact deposu NO_PROXY ile dışarıda bırakılır; NO_PROXY yazımı (baştaki nokta, joker, CIDR desteği) araçtan araca farklı yorumlandığı için her aracı ayrıca deneyin.
• Kimlik doğrulama yöntemi runner’a göre seçilir: bulut runner’ların çıkış adresi koşudan koşuya değişebildiği için kullanıcı adı ve şifre daha pratiktir; sabit IP’li kendi runner’ınızda IP whitelist düşünülebilir. Ürününüzde hangi yöntemlerin açık olduğunu panelde kontrol edin.
• Testlerden önce bir ön kontrol adımı koşar: her profilin çıkış ülkesi doğrulanır, uyuşmazlıkta iş “ortam sorunu” mesajıyla durur. Bu, kırk testin aynı nedenle kırılmasını beklemekten çok daha hızlı teşhis sağlar.
• Proxy’li projelerin eşzamanlılığı ve zaman aşımı ayrı ayarlanır; yerel ağda yazılmış sıkı zaman aşımları proxy üzerinden koşarken gereksiz kırmızı üretir.
• Yeniden deneme tek seferle sınırlanır ve yeniden denemeyle geçen test raporda ayrıca işaretlenir; sürekli yeniden denemeyle geçen bir test, gizlenmiş bir ortam sorunudur.
• Hata anında trace, ekran görüntüsü ve yanıt başlıkları artifact olarak saklanır; içlerindeki kimlik bilgileri ve test hesabı şifreleri saklamadan önce temizlenir.

Ön kontrol için en güvenilir yöntem, staging ortamınıza yalnız gizli bir test belirteciyle (örneğin özel bir istek başlığı) yanıt veren küçük bir hata ayıklama uç noktası eklemektir; istek proxy çıkışından, yani test ağının dışındaki bir adresten geldiği için erişimi ağ adresiyle değil belirteçle sınırlayın. Bu uç nokta sunucunun gördüğü istemci IP’sini, kendi geo veritabanınızın bu IP için döndürdüğü ülkeyi ve uygulamanın bu istek için verdiği kararları (para birimi, bölge, aktif feature flag’ler) döndürür. Üçüncü taraf bir “IP’m ne” hizmeti size proxy sağlayıcısının ya da o hizmetin veritabanının görüşünü verir; uygulamanızın kararı ise kendi veritabanınıza dayanır. Aşağıdaki betik bu uç noktayı her ülke profili için çağırır.

#!/usr/bin/env bash
# Geo QA ön kontrolü: her profilin çıkış ülkesini uygulamanın kendi geo kararıyla karşılaştırır.
# Her profil ayrı bir gizli değişkende tam proxy adresi olarak tutulur:
#   PROXY_URL_TR, PROXY_URL_DE, PROXY_URL_GB   (biçim: http://KULLANICI:ŞİFRE@GATEWAY:PORT)
#   GEO_DEBUG_TOKEN (hata ayıklama uç noktasının test belirteci)
# HEDEF_URL/geo-debug yalnız staging’de ve yalnız belirteçle açıktır ve JSON döndürür: {"ip": "...", "ulke": "DE", ...}
set -euo pipefail

for ULKE in TR DE GB; do
  PROXY="$(printenv "PROXY_URL_$ULKE")"
  YANIT="$(curl --silent --show-error --max-time 30 --proxy "$PROXY" -H "X-Geo-Debug-Token: $GEO_DEBUG_TOKEN" "$HEDEF_URL/geo-debug")"
  SUNUCU_ULKE="$(echo "$YANIT" | jq -r '.ulke')"
  echo "$(date -u +%FT%TZ) profil=$ULKE sunucu=$SUNUCU_ULKE" >> geo-on-kontrol.log
  if [ "$SUNUCU_ULKE" != "$ULKE" ]; then
    echo "ORTAM SORUNU: $ULKE profili $SUNUCU_ULKE olarak görünüyor; testler başlatılmadı." >&2
    exit 2
  fi
done
echo "Ön kontrol tamam: tüm profiller beklenen ülkeden çıkıyor."

Betikte uç nokta yanıtının JSON olduğu ve ülke kodunu “ulke” alanında döndürdüğü varsayılmıştır; kendi uç noktanızın biçimine göre uyarlayın. Ülke seçiminin nasıl yapıldığı (ayrı kullanıcı adı, ayrı uç nokta veya bir parametre) panelde tanımlıdır; betik bu ayrıntıdan bağımsız kalsın diye her profil kendi gizli değişkeninde tam proxy adresi olarak tutulur. Ön kontrol geçtikten sonra tarayıcı testleri başlar. Playwright kullanıyorsanız her ülke profilini ayrı bir proje olarak tanımlamak, dil ve saat dilimini çıkış ülkesiyle tutarlı tutmayı da kolaylaştırır.

import { defineConfig } from '@playwright/test'

// Her ülke profili ayrı bir proje. Değerler CI gizli değişkenlerinden gelir:
//   PROXY_SERVER_TR, PROXY_SERVER_DE, PROXY_SERVER_GB      (biçim: http://GATEWAY:PORT)
//   PROXY_KULLANICI_TR, PROXY_KULLANICI_DE, PROXY_KULLANICI_GB ve PROXY_SIFRE
// Ülke seçimi panelde kullanıcı adıyla ya da uç noktayla yapılıyor olabilir;
// ikisini de profil başına tutmak yapılandırmayı bu ayrıntıdan bağımsız kılar.
function profil(ad: string, ulke: string, dil: string, saatDilimi: string) {
  return {
    name: ad,
    use: {
      proxy: {
        server: process.env['PROXY_SERVER_' + ulke] ?? '',
        username: process.env['PROXY_KULLANICI_' + ulke],
        password: process.env.PROXY_SIFRE,
      },
      locale: dil,
      timezoneId: saatDilimi,
      serviceWorkers: 'block' as const,
    },
  }
}

export default defineConfig({
  testDir: './geo-testleri',
  timeout: 60_000,
  retries: 1,
  workers: 2,
  use: {
    baseURL: process.env.HEDEF_URL,
    trace: 'retain-on-failure',
    screenshot: 'only-on-failure',
  },
  projects: [
    profil('tr-residential', 'TR', 'tr-TR', 'Europe/Istanbul'),
    profil('de-residential', 'DE', 'de-DE', 'Europe/Berlin'),
    profil('gb-residential', 'GB', 'en-GB', 'Europe/London'),
  ],
})

// Tek profili yeniden koşmak için: npx playwright test --project=de-residential

Bu yapılandırmada service worker’ların engellenmesi bilinçli bir tercihtir: önbelleğe alınmış bir yanıt önceki koşunun geo kararını yeni koşuya taşıyabilir. Tarayıcının konum API’si de ayrı bir sinyaldir; uygulamanız haritada konum istiyorsa Playwright’ın konum ve izin seçeneklerini profile ayrıca ekleyin. Tek bir profili yeniden koşmak için proje adını komut satırında vermek yeterlidir; hata ayıklarken bütün matrisi tekrar çalıştırmanız gerekmez.

Mobil uygulamada trafiği proxy’ye yönlendirmenin iki temel yolu vardır: cihaz ya da emülatör düzeyinde sistem proxy’si tanımlamak veya uygulamanın debug yapısında ağ istemcisine proxy vermek. Birincisi kod değişikliği gerektirmez ama her trafiği kapsamayabilir; ikincisi tam kontrol sağlar ama üretim yapısıyla birebir aynı ağ yolunu test etmez. Pratikte ekipler ikisinin arasına yerel bir ara proxy koyarak esneklik kazanır.

Aşağıdaki sıra, tek bir sürüm için geo QA turunu tekrarlanabilir hâle getirir. Adımlar hem elle yürütülen testlere hem otomasyona uyar; otomasyonda her adım bir iş adımı ya da test kancası olur.

1. Değişikliği ve hipotezi yazın: “Bu sürümde Almanya ödeme ekranına banka havalesi eklendi; Almanya residential profilinde görünmeli, Türkiye profilinde görünmemeli.”
2. Matristen bu değişikliğin dokunduğu hücreleri seçin; çekirdek hücreleri her durumda listeye ekleyin.
3. Pazar başına sentetik test hesaplarını hazırlayın: adres, telefon biçimi ve mağaza hesabının ülkesi hücreyle tutarlı olsun; gerçek müşteri verisi kullanmayın.
4. Temiz bir başlangıç yapın: yeni tarayıcı bağlamı açın veya uygulama verisini silin; önbellek, çerez ve kayıtlı geo kararı önceki koşudan taşınmasın.
5. İstemci sinyallerini profile göre ayarlayın: dil, saat dilimi ve gerekiyorsa emülatör konumu çıkış ülkesiyle tutarlı ya da bilinçli olarak çelişkili olsun.
6. Ön kontrolü çalıştırın: sunucunun gördüğü IP’yi ve kendi geo veritabanınızın döndürdüğü ülkeyi kaydedin; beklenen ülke değilse koşuyu “ortam sorunu” olarak durdurun.
7. Senaryoyu yürütün: çok adımlı akışları sticky oturumla, tek istekli kontrolleri rotating oturumla (IPv4 Datacenter’da istek başına rotasyonla) koşun.
8. Kanıtı anında toplayın: ekran görüntüsü, trace veya HAR, yanıt başlıkları ve varsa uygulamanızın karar başlıkları; rotating çıkışta aynı IP’yi sonradan yeniden almak garanti değildir.
9. Sonucu kayıt şablonuna işleyin ve sınıflandırın; yalnız “ürün hatası” sınıfındaki kayıtları hata takip sistemine açın.
10. Aktarılan trafiği test aracının ölçümlerinden not edin ve bir sonraki turun kota tahminini bu ölçümle güncelleyin.

Bu adımların en çok atlananı dördüncüsüdür. Geo kararını çereze veya yerel depolamaya yazan uygulamalarda, önceki koşudan kalan bir değer yeni çıkış ülkesini tamamen gölgeleyebilir. Sonucun doğru görünmesi bu durumda bir tesadüftür; temiz başlangıç, sonucun gerçekten çıkış ülkesinden geldiğini güvenceye alan tek adımdır.

Geo hataları yeniden üretilmesi zor hatalardır. “Almanya’da fiyat yanlış görünüyordu” cümlesi, geliştiriciye hangi IP’den, hangi dil ayarıyla, hangi yapıyla ve hangi hesapla bakıldığını söylemez. Tutarlı bir kayıt şablonu bu soruları baştan yanıtlar ve aynı hatanın iki kişi tarafından iki farklı biçimde raporlanmasını önler.

Sınıflandırma, ekiplerin en çok zaman kaybettiği yeri düzeltir. Ürün hatası: çıkış ülkesi ve istemci sinyalleri doğru, davranış beklenenden farklı. Ortam sorunu: çıkış ülkesi beklenen ülke değil, proxy kimlik doğrulaması başarısız, zaman aşımı ya da ara proxy kesintisi var. Belirsiz: kendi geo veritabanınız çıkışı beklenmedik bir ülkeye eşledi ya da beklenen davranış hiç tanımlanmamış. Yalnız ürün hatası hata takip sistemine gider; ortam sorunları test altyapısının iş listesine, belirsizler ise ürün sahibine soru olarak düşer.

Tekrarlanabilirlik konusunda rotating proxy’nin doğasından gelen bir sınır vardır: hatayı gördüğünüz IP’yi sonradan yeniden almak garanti değildir. Bu yüzden kanıt anında toplanır ve yeniden üretim aynı ülke ve ağ türünden yeni bir çıkışla yapılır. Hata iki farklı IP’de tekrar ediyorsa büyük olasılıkla gerçek bir ürün hatasıdır; yalnız tek bir adreste görülüyorsa önce geo veritabanı eşlemesini kontrol edin. Kayıtlardaki IP’leri maskeli saklamak ve test hesaplarını sentetik tutmak, kayıt dosyalarının ekip dışına paylaşılmasını da kolaylaştırır.

Bir alışveriş uygulaması düşünün: Türkiye, Almanya, Birleşik Krallık, Hollanda, Fransa ve ABD’de yayında ve ayda iki sürüm çıkarıyor. Ekip her gece tarayıcı tabanlı bir geo smoke testi, her sürümden önce mobil uygulama regresyonu ve risk kuralı kontrolü koşuyor. Aşağıdaki hesaplarda sayfa ağırlığı, akış başına trafik ve tampon oranı varsayımdır; kendi pilot ölçümünüzle değiştirmeniz gerekir. Fiyatlar RotatingProxy kataloğundaki paketlerden alınmıştır; hesap kolaylığı için 1 GB = 1.000 MB kabul edilmiştir.

• Varsayım 1: Gece smoke testi her ülkede 20 sayfa yükler; proxy üzerinden aktarılan ortalama sayfa ağırlığı 3 MB’tır; ay 30 gecedir ve yeniden deneme ile başlık yükü için %20 tampon eklenir.
• Varsayım 2: Mobil regresyon her ülkede 8 akış koşar; akış başına trafik 15 MB’tır; ayda 2 sürüm vardır ve %25 tampon eklenir.
• Varsayım 3: Risk kuralı kontrolü her ülkede sürüm başına 50 API isteği gönderir; yanıt başına trafik 20 KB’tır.
• Varsayım 4: IPv6 hazırlık testi yalnız bir ay boyunca, tek eşzamanlı kanalla yapılır.

Tablonun okunuşu: tarayıcı tabanlı gece smoke testiyle aylık tüketim karşılığı yaklaşık 15,55 + 4,50 + 0,01 ≈ 20,06 USD’dir. Görselleri ve yazı tiplerini engellediğinizde aynı toplam yaklaşık 5,18 + 4,50 + 0,01 ≈ 9,69 USD’ye iner. Yani test tasarımındaki tek bir karar, paketler arasındaki birim fiyat farkından daha büyük etki yapar. Gece kontrolünü tarayıcı yerine API düzeyinde, her ülkede 30 istek ve istek başına 50 KB varsayımıyla yaparsanız tüketim ayda yaklaşık 0,27 GB’a, tamponla 0,32 GB’a düşer; residential birim fiyatıyla bu 0,40 USD’nin altında kalır.

İlk alım tutarı ayrı bir sorudur. Residential 20 GB (24 USD), Mobile 10 GB (25 USD) ve IPv4 Datacenter 10 GB (6 USD) paketleri birlikte 55 USD eder. Katalogda GB bazlı paketlerin süre sınırı olmadığı belirtildiği için bu tutar tek aya yayılmaz: varsayımlarla residential paket yaklaşık 1,5 ay (20 / 12,96), mobile paket yaklaşık 5,5 ay (10 / 1,8) yeter; datacenter paketi bu tüketim hızında pratikte bitmez ve asıl maliyeti en küçük uygun paketin fiyatıdır. IPv6 ürünleri port bazlı aylık faturalandığı için yalnız ihtiyaç duyulan ayda alınır; hem IPv6 Datacenter hem IPv6 Residential tek portla aynı ayda test edilecekse toplam 58 USD olur. Birden fazla eşzamanlı IPv6 kanalı gerekirse 5 portluk paket (80 USD) port başına 16 USD ile katalogdaki en düşük port fiyatını verir; 10 portluk pakette bu değer 17,50 USD’dir.

Birim fiyat farkları plan kurarken de yol gösterir. 10 GB kademesinde mobile’ın GB fiyatı (2,50 USD) datacenter’ın (0,60 USD) yaklaşık dört katı, residential’ın (1,20 USD) yaklaşık iki katıdır; en büyük 1.000 GB kademesinde bu değerler sırasıyla 2,10, 0,50 ve 0,90 USD’ye iner. Bu yüzden mobile kotası yalnız operatör adresinin testin konusu olduğu hücrelere ayrılmalı, geri kalan doğrulamalar daha ucuz ağ türlerine kaydırılmalıdır. Kurulumu denemek için GB bazlı üç ailede 2 GB’lık karşılama (1+1) paketleri bulunur: datacenter 1 USD, residential 2,5 USD, mobile 4 USD; koşulları sipariş ekranında görünür. Pilotta gerçek sayfa ağırlığını ve akış başına trafiği ölçüp yukarıdaki varsayımları kendi rakamlarınızla değiştirmek, paket boyutunu tahmin yerine veriyle seçmenizi sağlar.

Aşağıdaki tablo, geo QA’de sık karşılaşılan belirtileri ve bunların genellikle test kurulumundan mı yoksa üründen mi kaynaklandığını gösterir. Çoğu satırın çözümü proxy’de değil, profilin geri kalanındadır.

Tablodaki satırların çoğu ürün hatasına değil, test profilinin kurulumuna işaret eder. Ön kontrol adımını ve temiz başlangıcı ihmal etmeyen bir ekip bu satırların büyük kısmını hiç yaşamaz; yaşadığında da sorunu dakikalar içinde “ortam” ya da “ürün” diye ayırabilir.

Bir geo QA turunu tamamlanmış saymadan önce aşağıdaki maddeleri gözden geçirin. Liste hem otomasyon hattı hem elle yürütülen testler için geçerlidir.

• Lokasyon envanteri güncel; bu sürümde eklenen veya değişen her geo kararının sinyali ve beklenen davranışı yazılı.
• Sürüm matrisi seçildi; çekirdek hücreler ve değişikliğin dokunduğu hücreler listede.
• Her hücrenin ağ türü testin sorusuna göre seçildi; mobile kotası yalnız operatör adresi gerektiren hücrelere ayrıldı.
• Test hesapları sentetik; adres, telefon ve mağaza ülkesi hücreyle tutarlı.
• Proxy kimlik bilgileri gizli değişkende; loglar, HAR dosyaları ve artifact’lar kimlik bilgisinden arındırılmış.
• Proxy yalnız test adımında veya tarayıcı bağlamında tanımlı; NO_PROXY listesi kullanılan araçlarla denendi.
• Ön kontrol her profilin çıkış ülkesini kendi geo veritabanınızla doğruladı; uyuşmazlıkta koşu ortam sorunu olarak durdu.
• Dil, saat dilimi ve gerekiyorsa konum her profilde çıkış ülkesiyle tutarlı ya da bilinçli olarak çelişkili.
• Çok adımlı akışlar sticky oturumla, tek istekli kontroller rotating oturumla koştu; IP değişimi ayrı bir vaka olarak test edildi.
• Mobil testlerde bütün alan adlarının proxy’den geçtiği ara proxy kayıtlarıyla doğrulandı; HTTP/3 ve DNS çözümleme yeri kontrol edildi.
• Her sonuç kayıt şablonuna işlendi ve sınıflandırıldı; yalnız ürün hataları hata takibine açıldı.
• Aktarılan trafik ölçüldü; bir sonraki turun kota tahmini ve paket seçimi bu ölçümle güncellendi.

Bu liste ilk turlarda uzun görünebilir; birkaç sürüm sonra maddelerin çoğu otomasyon hattının kendiliğinden kontrol ettiği adımlara dönüşür ve geriye envanteri güncel tutmak ile sonuçları doğru sınıflandırmak kalır. Rotating proxy bu düzenin yalnız bir bileşenidir: ağ çıkışını kontrol etmenin ucuz ve tekrarlanabilir yolu. Asıl değer, uygulamanızın lokasyona bağlı kararlarını yazılı, ölçülebilir ve her sürümde yeniden doğrulanabilir hâle getirmekten gelir.