Celebrate the creativity and courage of testers and quality engineers as they share stories, lessons, and ideas in just 99 seconds.

What is Localisation Testing?Localisation testing is the process of confirming that an application behaves as expected in each supported region. These regions could be broad — such as an EU-wide version of a site — or highly specific, like a custom landing page designed only for visitors from a single city. How does a website know where the user is?There are two main methods: IP Geolocation The website looks up the visitor’s IP address in a geolocation database to estimate their location. These databases are generally very accurate at the country level, and can sometimes narrow down to the city — though with less reliability. This method requires no input from the user. Browser Location API Modern browsers can provide precise location data using signals like GPS, nearby Wi-Fi networks, or cell towers. Unlike IP geolocation, this usually requires the user’s explicit permission before sharing. How do websites change their content?Websites typically use one of three approaches: Redirect to a country-specific TLD For example, a visitor from the UK navigating to example.com would be redirected to example.co.uk. Redirect to a region-specific path For example, a visitor from the UK landing on example.com would instead be taken to example.com/uk/. Serve location-specific content at the same URL In this case, the page at example.com shows different content depending on whether the visitor is in the UK or the USA — while keeping the same address. Is this how websites decide what language to use?Not always. While some websites rely on location to select a language, the better approach is to respect the user’s Accept-Language header. This allows people to choose their preferred language independent of their physical location. For example: A user in the UK may prefer to browse in French. A user in France may prefer to browse in English. What sort of content is localised?The specifics depend on the site, but common examples include: Displaying GDPR cookie banners to users in Europe, but not elsewhere. Showing region-specific content (e.g. Netflix only lists shows licensed in that region). Adjusting pricing to reflect local currencies and market expectations. What are the key steps in localisation testing? Identify the regions that have unique content You can’t test what you don’t know to look for. Start by mapping out which versions of the site exist (country, region, or city level) and what differs between them. Decide how to access region-specific versions of the site Common solutions include using proxy servers, VPNs, or test hooks built into the application that let you simulate being in a different location. Test from each location Verify that the actual behaviour matches the intended behaviour for each region. Be mindful of edge cases — for example, location-specific changes accidentally breaking other parts of the site.

Compliance Testing Compliance testing is the process of ensuring that a website or application meets relevant legal and regulatory requirements. This is becoming increasingly challenging as different regions and countries legislate their own standards. What’s essential in one jurisdiction may create needless friction in another—or fail to meet the bar in a third. Requirements can cover many areas, including accessibility, data storage, third-party cookie consent, language and currency presentation, and more. How should I get started? Identify what to test, and where it applies. Create a list (a spreadsheet works well) that maps compliance requirements to the regions where they matter. Don’t just confirm that the required elements appear (or don’t)—also check for unintended side effects. For example, you don’t want a cookie banner breaking the checkout flow. Determine how you’ll view the right version of your site. Some sites show the same compliance elements to everyone (e.g., cookie banners everywhere). Others detect a visitor’s region and adapt accordingly. In those cases, you may need a testing tool that lets you appear to be in different locations. Run your tests. Once your requirements and methods are clear, you can systematically verify that each compliance element behaves as expected across regions.

Testing Environments Many organizations maintain multiple “environments” (or “copies” of their website or product) that serve different purposes. A simple setup might include Development, QA, Staging, and Production. Larger organizations may have multiples of each, and some even run dozens or hundreds of environments in parallel as different pieces of work progress. A testing environment is an environment specifically designed for testing. It contains a working copy of the system under test, along with the supporting resources needed for it to function properly. These resources are usually other “testing” versions of services, so testers can safely simulate scenarios—like checking out with a credit card—without touching real systems or data. Common challenges in testing environments Non-functional pieces It’s common for some parts of the site to be missing or disabled in a testing environment. Integrations may not be wired up, certain services may be too costly to replicate, or features like email delivery may be switched off to avoid accidentally contacting real users. As a result, additional test runs may be needed once code reaches production. Insufficient test data If the attached database only contains a handful of users or products, issues that occur at real-world scale may never surface. These can range from crippling performance problems to subtle UI issues that only appear when datasets are larger. Messy environment state Over time, testing environments can accumulate abandoned carts, half-finished registrations, and spam data. This “junk” makes it hard to run clean scenarios and can interfere with tests that depend on a fresh start. Best practices for testing environments Keep them production-like. The closer an environment matches production in configuration and integrations, the more reliable the test results will be. Manage test data thoughtfully. Use representative data volumes and refresh it regularly to uncover performance and usability issues earlier. Automate resets. Provide tools or scripts to reset state between runs, ensuring cleaner, repeatable tests. Document differences. If certain features are intentionally disabled (e.g. email), make that clear so testers know what to expect. Automate test data creation. Having fresh accounts, products, or pages created at the click of a button is convenient and avoids the problem of sharing test accounts between multiple testers. Use realistic data. Resist the temptation to fill fields with random keystrokes. It’s much easier to spot problems when test data resembles real-world inputs. Tools like Fakery can generate meaningful fake data on demand. Mimic production structures. Most organizations rightly forbid using real production data in test environments. Still, it’s valuable to study complex production data and replicate its structure in development to surface issues earlier. Include geo-awareness. Many compliance and localization issues only appear in specific countries. Using a geo-proxy service such as WonderProxy helps ensure your test environments behave correctly for users around the world.