A region-specific QA checklist for releases, run from the browser

Region-specific QA is the part of a release check that asks what a visitor in another country gets: a different price or currency, a consent banner, a redirect to a regional domain, a feature switched off, or a refusal. Those differences are usually decided from the visitor's IP address, so they cannot be checked from the office network. This checklist runs the checks from a normal browser with the ProxyForge browser extension, sending only the hosts under test through proxies in the countries you care about. The steps work the same with any per-site proxy setup.

Before the release: decide what "region" means for this change

Write down the countries the change behaves differently in, and the hosts that decide it. For most releases that is more than the page itself:

• the application host serving the page
• the API host the page calls for prices, availability or consent rules
• the CDN host, if regional assets or redirects are configured there

Then decide what the target uses besides the IP address. Many sites also read Accept-Language, the time zone the browser reports, and the country saved on a signed-in account. A proxy changes only the IP; geo-targeting proxies covers the other signals and how to keep the browser consistent with the exit country.

Choose the proxy line for each country as well. A check that should reflect consumer traffic is closer to real conditions through ISP or residential addresses than through a datacenter range; ISP vs datacenter proxies sets out how targets treat each.

Route only the hosts under test

Use Per site mode so that only the hosts in the plan go through a proxy and the rest of the browser, including single sign-on, ticketing and chat, stays direct. Rules are read top to bottom and the first match wins. A plain host matches only itself, so cover a host and its subdomains with two lines:

To check a second country, change the proxy on those rows rather than adding a second set: two rules for the same host never both apply, because the first one decides. Keep the rule list in the release runbook as plain text, one per line, so the next person can paste the same set. The extension setup guide shows the Rules page and the full matching syntax.

Check each proxy before you trust a result

A result is only as good as the exit it came through. Before a session:

1. Run Test on every proxy in the plan. It sends a request to the IP check through that proxy without moving your tabs, and records the outcome, the round-trip time and the exit IP. A result older than 30 minutes is marked stale; test again rather than rely on it.
2. Connect, open the popup and read the exit IP and country the check reported.
3. Where a result surprises you, ask the same endpoint from a terminal through the same proxy and compare:

curl -s -x http://USER:PASS@HOST:PORT https://api.proxyforge.io/tools/echo

Geolocation databases disagree, particularly below country level, so a site may place an address differently from the check. That is a finding to record, not a reason to discard the result.

Leave failover and switch-on-block off for QA sessions; both are off by default. Each one replaces the connected proxy when it fails or when a listed site answers 403 or 429, and a QA record needs to know exactly which exit served the page.

Run the checks

For each country in the plan, against the release candidate and against production as a baseline:

1. Load the entry pages through the proxy and note the status: a 403 or 429 is a result in its own right. Proxy 429 and 403 errors helps tell the target's refusal from the proxy's.
2. Check currency, price, tax display and number formats.
3. Check the language served and whether a language switcher overrides it.
4. Check the consent banner: whether it appears, which choices it offers, and what loads before an answer.
5. Follow redirects to regional domains or paths, and check they land where the plan says.
6. Walk the flow the release changed as far as it goes without real money or real accounts.
7. Repeat the differences you found through a second proxy in the same country, so a quirk of one address is not filed as a country rule.

Use a clean profile for each country, or clear site data between runs. Cookies and local storage set during a German session will otherwise follow you into the French one, and the site may honour the stored choice over the new address. Private windows work too, once the browser allows the extension in them. Until then the popup notes that it is not allowed there: Firefox private windows connect directly, and in a Chrome Incognito window a site can ask for a proxy password.

Know what the browser view cannot show

Some outcomes do not announce themselves:

• A captcha or interstitial page that answers with status 200 looks like a normal page to the extension. Switch-on-block reacts to 403 and 429 only.
• A rotating gateway keeps its exit IP until its own session changes. Switching moves to another stored proxy; it cannot make a gateway hand out a new exit.
• Caches between the site and you can hold a regional variant. When production and the release candidate disagree, check whether the CDN host is in your rules.
• A proxy changes the network path, not the browser. Fonts, the operating system's locale and the browser's language stay yours.

Record what you saw

A useful record lets someone repeat the check without asking you. For each finding capture:

• the country, the proxy's label and the exit IP shown in the popup
• the time, the URL and the build under test
• the result through the second proxy, if you ran one
• a screenshot of the page and, for a refusal, the status code

Checks that need repeating every release are worth automating once the manual pass has settled what to look for. A script or Playwright suite on a workstation or build box can run through ProxyDesk, which puts the same proxies behind one local address and refuses connections rather than sending them direct when none is working. For the manual pass, the browser extension is the quicker tool.