What Selenium is and why teams use it
Selenium is a set of tools for browser automation: your test code controls Chrome/Firefox/Edge the way a real user would. It is widely used for web QA to validate critical flows (login, sign‑up, cart, checkout), for regression suites after releases, and for monitoring (periodically opening pages and capturing failures).
Because Selenium drives a real browser, it executes JavaScript, follows redirects, preserves cookies and storage, and is much closer to real user behavior than a plain HTTP client.
Common use cases
- Functional web QA: end‑to‑end flows across pages and services.
- Regression testing: quick checks to ensure old features still work.
- Smoke tests: short pre‑deploy validation.
- Monitoring: availability, frontend errors, content drift.
- Localization validation: language, currency, shipping, payments, and content.
Execution modes: local, headless, Grid/Remote
- Local: driver and browser run on the same machine as the tests.
- Headless: no visible window (typical in CI); fast, but some sites behave differently.
- Selenium Grid / RemoteWebDriver: browsers run on remote nodes (Docker/VM) for parallelism.
In all modes, the most reliable approach is to set the proxy at session start using options/capabilities, as defined by the WebDriver spec and Selenium documentation.
Where to configure a proxy in Selenium
- W3C “proxy” capability: a JSON object nested in capabilities (portable across browsers).
- Selenium Proxy object: exposes http/ssl/socks/noProxy settings that you attach to the driver/options.
- Browser-native switches: Chromium supports
--proxy-server,--no-proxy-server, and auto-detect flags.
Proxy modes you will see in practice
Most QA teams use manual (explicit host/port). PAC and auto-detect can be useful in corporate environments but reduce determinism in CI. “direct” is handy to ensure the browser does not inherit system proxy settings.
Why mobile proxies
Mobile proxies route traffic through IP addresses assigned to mobile carriers (4G/5G). For geo QA, this matters when you want to replicate not only a “mobile UI” (viewport/User‑Agent) but also the network identity signals a site may use: mobile ASN, NAT/CGNAT characteristics, routing, and IP reputation.
Dedicated mobile proxies (one channel/modem per team or per parallel test worker) reduce cross‑test interference and “IP contamination,” making country‑to‑country comparisons easier to explain.
Geo QA on mobile IPs: what tends to change
- currency and pricing rules;
- catalog availability and stock constraints;
- shipping and payment methods;
- local legal banners and content variants;
- anti‑bot behavior: captchas and extra verification steps.
Sticky IP: when it’s worth paying for
Sticky IP means the same egress IP is kept for a defined period. It is especially important for multi‑step flows (sign‑up → verification → checkout): an IP change mid‑flow can break sessions or trigger risk checks. For large regression runs, overly long stickiness can be counterproductive; align the sticky window with the scope of a single test case or a single worker.
Grid/Docker caveats
- the proxy must be reachable from the node where the browser actually runs;
- separate “test client → Grid” traffic from “browser → Internet via proxy” routing;
- store proxy credentials in CI secrets, not in source code;
- save artifacts per country and per worker (screenshots, logs, reports).
Case study: registration and checkout in 3 countries
A QA team validates a product in three countries and wants to capture differences in content and pricing specifically from mobile networks.
- 3 dedicated mobile proxies (one per country), 30‑minute sticky window;
- separate CI runs via a COUNTRY parameter;
- same browser/driver versions and the same test data across runs.
Each run logs the current IP and country, UI language/currency, prices for control items, available shipping/payment methods, captcha presence during sign‑up, and geo redirects to local domains. Typical findings include tax/promo-driven pricing deltas, missing payment methods in one country, or captchas that only appear on mobile carrier IPs.
Practical tips for repeatable results
- start with a clean browser profile; clear cookies and storage between countries;
- use one sticky session per parallel worker;
- increase timeouts and differentiate network flakiness from product bugs;
- avoid overloading a single mobile channel with excessive concurrency;
- include IP/country/time and proxy method (capabilities/flags) in reports.