Tim menguji aplikasi selama satu sprint, merilis build — dan seminggu kemudian, keluhan mulai masuk ke dukungan: “di kota saya harganya berbeda”, “push tidak datang”, “saya tidak bisa membayar dengan kartu”. Penyebabnya hampir selalu sama: semua pengujian dilakukan dari satu IP korporat, sedangkan pengguna nyata mengakses dari daerah, jaringan, dan operator yang berbeda. Dalam artikel ini, kita akan membahas 7 skenario QA konkret yang secara fisik tidak mungkin diuji tanpa mengganti alamat IP, dan menunjukkan bagaimana mengatur infrastruktur pengujian dengan proxy.
Mengapa IP kantor adalah zona buta QA
Sebagian besar aplikasi mobile saat ini mengambil keputusan berdasarkan alamat IP: menentukan negara pengguna, bahasa antarmuka, mata uang, metode pembayaran yang tersedia, set fitur, dan bahkan harga langganan. Ketika seluruh departemen QA menguji dari satu kantor dengan satu IP statis dari pusat data atau jaringan korporat, aplikasi selalu menerima jawaban yang sama dari backend — seolah-olah semua penguji berada di satu titik di dunia.
Akibatnya, bug yang bergantung pada geolokasi, waktu di zona waktu, operator seluler, atau jenis koneksi, tidak dapat direproduksi di lingkungan pengujian. Mereka muncul hanya di produksi — ketika pengguna dari Kazakhstan melihat harga dalam rubel, pengguna Jerman tidak menerima push karena pemblokiran GCM di jaringannya, dan pelanggan Indonesia tidak dapat membayar dengan kartu karena penyedia pembayaran untuk wilayahnya tidak terhubung. Memperbaiki bug seperti itu setelah rilis jauh lebih mahal daripada menangkapnya di tahap QA.
Solusinya adalah untuk meniru keragaman geografis dan jaringan pengguna yang nyata sebelum rilis. Untuk itu, insinyur QA semakin sering menggunakan server proxy: mereka memungkinkan untuk "memindahkan" perangkat pengujian atau emulator ke negara, kota, atau bahkan operator seluler mana pun tanpa perlu pergi ke sana secara fisik atau membeli puluhan kartu SIM.
Skenario 1: Geokonten dan harga regional
Sebagian besar aplikasi dengan langganan (streaming, kebugaran, pendidikan) menunjukkan harga yang berbeda di negara yang berbeda — ini disebut geoharga. Jika QA memeriksa pendaftaran langganan hanya dengan IP lokal, tidak mungkin untuk memastikan bahwa harga untuk pengguna dari Turki, Brasil, atau India ditampilkan dengan benar, dalam mata uang yang tepat dan dengan pembulatan yang benar.
Masalah yang sama berlaku untuk katalog konten: perpustakaan film, produk, atau penawaran sering bersifat regional. Diperlukan untuk secara fisik "muncul" di negara yang tepat untuk melihat layar yang sama yang dilihat oleh pengguna nyata. Untuk pemeriksaan semacam itu, sangat nyaman menggunakan proxy residensial — mereka memberikan IP pengguna rumah nyata dari negara tertentu, dan backend aplikasi menganggap permintaan sebagai lalu lintas organik biasa, bukan sebagai permintaan dari pusat data.
Pemeriksaan praktis: jalankan skenario pendaftaran langganan di 8-10 pasar kunci (AS, Jerman, Brasil, India, Turki, Jepang, Nigeria, UEA), ambil tangkapan layar harga dan mata uang, dan bandingkan dengan daftar harga produk. Ini menutup sebagian besar keluhan seperti “mengapa harga saya berbeda”.
Skenario 2: Geoblokir dan pembatasan akses
Aplikasi fintech, layanan streaming, dan beberapa game memblokir akses dari negara tertentu karena alasan hukum atau lisensi. QA harus memastikan tidak hanya bahwa aplikasi berfungsi di tempat yang seharusnya, tetapi juga bahwa aplikasi dengan benar (dan tidak dengan crash) menolak akses di tempat yang tidak seharusnya.
Bug yang khas: alih-alih layar rapi "layanan tidak tersedia di wilayah Anda", pengguna melihat layar putih atau loader yang tidak berujung — karena pengembang hanya menguji jalur bahagia dari negara yang diizinkan. Memeriksa geoblokir memerlukan koneksi berurutan dari beberapa yurisdiksi terlarang, yang tidak realistis dengan kartu SIM fisik dan perjalanan dinas, tetapi melalui proxy memerlukan 10-15 menit per negara.
Untuk skenario ini, proxy dengan geolokasi yang tepat pada tingkat kota, bukan hanya negara — penting untuk memeriksa bukan "Jerman secara umum", tetapi tanah tertentu, jika lisensi dibatasi oleh wilayah di dalam negara.
Skenario 3: A/B dan rollout bertahap berdasarkan negara
Fitur-fitur dan rollout bertahap hampir selalu diatur dengan pengikatan ke geolokasi: fitur baru pertama kali diaktifkan di Kanada, seminggu kemudian — di Australia, lalu — di mana-mana. Jika tim QA secara fisik berada di satu negara, mereka pada prinsipnya tidak dapat melihat versi baru sebelum wilayah lain, sampai bendera mencapai mereka.
Untuk menguji fitur sebelum rilis global, perlu untuk mengganti geolokasi ke negara gelombang pertama rollout. Ini adalah salah satu tugas paling umum yang diselesaikan oleh proxy dalam kombinasi dengan browser anti-deteksi atau emulator perangkat — mengganti IP ke negara yang diinginkan, memulai ulang sesi aplikasi, melihat fitur lebih awal daripada pengguna lain dan menemukan bug sebelum bendera mencapai 100% audiens.
Nuansa penting: untuk A/B testing diperlukan "pendaftaran" IP yang stabil selama seluruh siklus pengujian — sesi tidak boleh melompat-lompat antar negara antara permintaan, jika tidak backend akan bingung dengan kondisi eksperimen dan menunjukkan baik grup kontrol maupun grup uji.
Skenario 4: Lokalisasi dan push-notifikasi
Teks push-notifikasi, waktu pengirimannya, dan bahkan fakta pengiriman itu sendiri sering bergantung pada geolokasi perangkat. Di beberapa negara, penyedia push (Firebase, APNs, gerbang SMS lokal) bekerja dengan penundaan atau melalui rute alternatif — dan apa yang dengan baik dikirim di lingkungan pengujian dari kantor di Moskow, mungkin tidak sampai ke pengguna di Indonesia karena pemblokiran server push tertentu oleh penyedia jaringan lokal.
Selain itu, lokalisasi antarmuka sering dipicu berdasarkan IP, bukan hanya berdasarkan bahasa sistem: pengguna dengan bahasa Inggris di ponsel, tetapi IP dari Prancis, dapat melihat antarmuka campuran — judul dalam bahasa Prancis, tombol dalam bahasa Inggris. Bug semacam ini 100% tidak terlihat jika seluruh QA menguji dari satu zona geo.
Proses yang direkomendasikan: ambil 5-7 lokal dari pasar prioritas produk, sambungkan melalui proxy dengan IP yang sesuai, ubah bahasa sistem di perangkat/emulator dan catat teks serta format tanggal/angka yang ditampilkan aplikasi. Ketidaksesuaian antara negara IP dan bahasa sistem adalah kasus wajib yang terpisah, sering kali dilupakan.
Skenario 5: Metode pembayaran dan sistem anti-fraud
Set metode pembayaran yang tersedia dalam aplikasi mobile hampir selalu bergantung pada negara: di satu wilayah pembayaran dengan kartu dan Apple Pay tersedia, di wilayah lain hanya dompet lokal (Mercado Pago, Boleto, UPI, QIWI), di wilayah ketiga — pembayaran melalui operator seluler. Jika QA tidak dapat terhubung dari negara yang diperlukan, setengah dari skenario pembayaran tetap tidak teruji hingga produksi, di mana harga kesalahannya adalah kehilangan pendapatan dan keluhan ke dukungan.
Rasa sakit yang terpisah — sistem anti-fraud penyedia pembayaran. Mereka menilai risiko transaksi juga berdasarkan IP: permintaan dari IP pusat data hampir pasti akan ditolak atau memerlukan pemeriksaan 3D-Secure tambahan, bahkan jika kartu tersebut sepenuhnya valid. Ini mengaburkan hasil pengujian: QA melihat penolakan pembayaran dan melaporkan bug kepada pengembang, padahal masalahnya bukan di kode, tetapi pada kenyataan bahwa IP pengujian terlihat mencurigakan untuk penilaian anti-fraud.
Untuk skenario pembayaran, lebih baik menggunakan proxy residensial atau proxy mobile — mereka terlihat seperti lalu lintas pengguna nyata dan tidak memicu pemicu tambahan dari sistem anti-fraud, yang memberikan gambaran yang lebih jujur tentang perilaku aliran pembayaran.
Skenario 6: Perilaku dalam jaringan mobile operator
Aplikasi yang berfungsi dengan baik di Wi-Fi kantor pada 200 Mbit/s, dapat berperilaku sangat berbeda dalam jaringan mobile 3G/4G dengan koneksi yang tidak stabil, proxy NAT operator, dan latensi tinggi. Timeout permintaan, percobaan ulang, degradasi kualitas video/audio, dan operasi mode offline — semua ini sangat penting untuk diuji dalam kondisi yang mendekati internet mobile, bukan hanya di jaringan kantor yang stabil.
Kesulitan tambahan: beberapa operator seluler menerapkan proxy dan CGNAT mereka sendiri, yang membuat server melihat bukan IP nyata pengguna, tetapi IP umum operator, yang dilalui oleh ribuan pelanggan secara bersamaan. Ini mempengaruhi pembatasan laju dan geolokasi berdasarkan IP — aplikasi dapat "berpikir" bahwa pengguna berada di kota lain daripada yang sebenarnya.
Untuk mereproduksi perilaku semacam itu, diperlukan proxy mobile yang terhubung ke internet melalui kartu SIM nyata dari operator negara yang diperlukan — ini memberikan gambaran yang akurat tentang NAT, latensi, dan kecepatan, yang tidak dapat diperoleh dari IP pusat data biasa.
Skenario 7: Pembatasan laju dan perlindungan dari bot
Banyak API backend aplikasi mobile membatasi jumlah permintaan dari satu IP (pembatasan laju) dan menggunakan perlindungan dari bot, mirip dengan captcha atau analisis perilaku. Jika tim QA menjalankan autotest dari satu IP korporat, setelah beberapa waktu server mulai merespons dengan kesalahan 429 atau memblokir permintaan sepenuhnya — dan pengujian gagal bukan karena bug dalam aplikasi, tetapi karena backend menganggap lalu lintas pengujian sebagai serangan.
Ini sangat relevan untuk pengujian beban dan regresi, ketika dalam waktu singkat perlu melakukan ratusan permintaan serupa (pendaftaran, login, menambahkan ke keranjang). Distribusi permintaan di antara berbagai IP melalui kumpulan proxy memungkinkan untuk memberikan beban yang adil pada API tanpa distorsi hasil karena pemicu perlindungan anti-fraud.
Untuk pengujian otomatisasi massal semacam itu, sering kali lebih menguntungkan untuk menggunakan proxy pusat data — mereka lebih cepat dan lebih murah dalam volume permintaan yang besar, dan geolokasi dalam skenario ini tidak begitu kritis seperti kecepatan dan stabilitas koneksi.
Alat dan pengaturan proxy untuk QA
Untuk QA manual pada emulator (Android Studio Emulator, Xcode Simulator), proxy diatur melalui pengaturan jaringan sistem emulator: Anda menentukan IP dan port server proxy, login dan kata sandi, jika autentikasi digunakan. Untuk perangkat nyata, pengaturan serupa tersedia dalam koneksi Wi-Fi melalui “Pengaturan Lanjutan → Proxy → Manual”.
Untuk menangkap dan menganalisis lalu lintas antara aplikasi dan backend, insinyur QA menggunakan Charles Proxy atau Proxyman — kedua alat ini memungkinkan untuk melewatkan lalu lintas aplikasi melalui proxy eksternal dan sekaligus melihat semua permintaan HTTP/HTTPS, header geolokasi, dan respons server. Ini nyaman untuk diagnosis: segera terlihat IP mana dan negara mana yang "dilihat" backend pada saat permintaan.
Untuk pengujian otomatisasi melalui Appium atau Espresso, proxy ditentukan dalam kemampuan yang diinginkan dari sesi atau melalui pengaturan sistem perangkat sebelum menjalankan rangkaian pengujian. Platform cloud untuk pengujian aplikasi mobile (BrowserStack, Sauce Labs) juga mendukung koneksi proxy kustom, yang memungkinkan untuk menjalankan skenario autotest yang sama dari negara yang berbeda tanpa perangkat fisik di setiap titik di dunia.
Jika dalam tim ada versi web aplikasi atau perlu menguji beberapa akun secara bersamaan dengan geolokasi yang berbeda, nyaman untuk menggunakan browser anti-deteksi (Dolphin Anty, AdsPower, Multilogin) — setiap profil terikat pada proxy terpisah, dan insinyur QA dapat menjaga 5-10 sesi terbuka dari negara yang berbeda secara bersamaan tanpa kebingungan dalam cookie dan cache.
Jenis proxy yang dipilih untuk setiap skenario
| Skenario QA | Jenis proxy yang direkomendasikan | Mengapa |
|---|---|---|
| Geoharga dan konten | Residen | Terlihat seperti lalu lintas pengguna biasa, tidak memicu perlindungan anti-bot |
| Geoblokir | Residen | Geolokasi yang tepat hingga kota/wilayah |
| A/B dan rollout | Residen / pusat data | Sesi yang stabil sepanjang siklus pengujian |
| Push dan lokalisasi | Mobile | Mereproduksi kondisi pengiriman yang nyata melalui operator |
| Pembayaran dan anti-fraud | Residen / mobile | Risiko rendah untuk pemicu palsu dari sistem anti-fraud |
| Jaringan mobile operator | Mobile | Kartu SIM nyata dari operator, emulasi NAT dan latensi yang tepat |
| Pembatasan laju / pengujian beban | Pusat data | Kecepatan tinggi dan biaya rendah untuk volume permintaan besar |
Checklist sebelum rilis
Sebelum merilis build ke produksi, lakukan pemeriksaan singkat terkait geolokasi dan jaringan — ini menutup sebagian besar bug yang dijelaskan di atas:
- Harga dan mata uang langganan diperiksa setidaknya di 5 pasar kunci produk
- Pemeriksaan tampilan layar geoblokir yang benar di negara terlarang
- Fitur bendera diuji di negara gelombang pertama rollout sebelum rilis global
- Push-notifikasi diperiksa dengan IP dan bahasa sistem dari kombinasi negara yang berbeda
- Metode pembayaran yang tersedia diperiksa untuk setiap wilayah kunci secara terpisah
- Aliran pembayaran diuji tanpa pemicu palsu dari sistem anti-fraud
- Aplikasi diuji dalam kondisi jaringan mobile (3G/4G), bukan hanya Wi-Fi
- Autotest tidak gagal karena pembatasan laju saat dijalankan secara paralel dari satu IP
Kesimpulan
Aplikasi mobile hidup di puluhan negara, jaringan, dan ekosistem pembayaran secara bersamaan, sementara tim QA secara fisik duduk di satu kantor dengan satu IP. Justru kesenjangan ini antara audiens nyata dan kondisi pengujian yang melahirkan sebagian besar bug "tak terjelaskan" yang sampai ke produksi. Tujuh skenario di atas — geoharga, geoblokir, rollout A/B, push dan lokalisasi, pembayaran, jaringan mobile operator, dan pembatasan laju — menutup sebagian besar risiko semacam itu.
Jika tim Anda menguji aplikasi yang bekerja dengan konten regional, harga, atau pembayaran, masuk akal untuk menghubungkan proxy residensial ke tumpukan pengujian untuk meniru pengguna nyata, dan untuk skenario dengan koneksi mobile dan pengiriman push — proxy mobile yang terikat pada operator tertentu. Ini memungkinkan untuk menemukan bug kritis di tahap QA, bukan setelah keluhan pengguna di toko.