How Do We Test Web Applications That Use GeoIP for Localization?
Have you ever opened Google Maps on your computer only to find the map loaded on or near your current location? Or maybe you’ve been travelling outside the US and when you browsed to your favourite newspaper site you were redirected to their international version? Most businesses have a desire to know where their users are to help customize or tailor the experience in some way (sometimes called localization). In our newspaper example, by knowing our location, the newspaper can show us content that might be more useful right now. This is great for customers, but as a business, how does our software development team test for this type of dynamic functionality?
Background
Businesses that want to know the location of users coming to their site can use a technology called GeoIP, which means:
“... the process of determining your geography based on your IP address. When you load up a website, stream music, or download a game, the server that provides it to you sees your IP address, kind of like telephone call display or a return address on an envelope.”
Even more impressive is how straightforward the process is. Let’s use IP Location Finder as an example to try it ourselves. Go to https://www.iplocation.net/ and let it lookup your location by your IP Address. See all of the information it was able to find out about you and your relative locale?
Based on this information, a business can adjust functionality such as pinning your location on a map (think Google Maps), showing you different versions of a website (think international newspaper edition), updating the site’s language, or adjusting the currency for purchasing goods (such as from US Dollars to Philippines Pesos).
As a development team, we would be expected to develop, test, and deploy these geolocation features. This inevitably raises the question: how do we test for a localized experience if our IP address is nowhere near the locations we want to test?
Taking Action to Test
There are three common ways to test applications using GeoIP or other forms of Geolocation technology:
- Hack it using cookies or GET vars to change your locale.
- Hire staff or a local vendor to do the testing for you.
- Test it yourself using proxies to make your internet traffic appear to be in the right locale.
Let’s look at each of these approaches individually:
Hack It
By far the cheapest option: we hack our application into thinking we’re coming from a different IP address. Depending on our implementation, we can either edit a cookie or modify the GET vars in an API request to adjust our locale. Using IP Location Finder as an example we can do this with a simple query parameter:
https://www.iplocation.net/?query=<newipaddress> such as
https://www.iplocation.net/?query=159.8.170.20
Now our location becomes this new location based on the IP address we entered. While this method is fine for doing some initial exploratory testing we need to be careful because we run the risk of testing the work-around and not the code we’ve written for different geolocations. If we take this a step further, do we allow hacking our IP address in production so we can replicate potential bugs reported to us or are we left without the ability to replicate them?
Staff It
By far the most expensive option: we hire people in our target locales to do our testing and help with any additional support we may need. This used to be a prime area for crowdsourced testing but now seems to be supported by a lot of specialty localization shops happy to help you. Great if you have the resources and time but usually not an option for most of us.
Proxy It
The middle ground and best referenced option: do the testing yourself using a proxy to make your internet traffic appear to be in the right locale. Proxies route your traffic to servers in the chosen locale and then your web application's geolocation features do their thing. Unlike the hacking option, when you test your application using a proxy, you are testing your geolocation functionality (code) itself, and not the hack, so you can safely assume that whatever information you find (bugs or otherwise) is accurate.
Unlike the staffing solution, proxies are both a short term and long term solution, and without much of the cost. We can do our initial exploratory testing with the proxy and then later automate some of that testing while adding it to our build pipeline as part of our continuous testing strategy.
Wrapping Up
Businesses of all kinds use GeoIP to better serve customers across various locations around the world. Building these localization features creates challenges around how our software development team (testers and developers) test for this dynamic functionality. Of the three solutions we’ve laid out, one gives you a middle ground that can help you overcome these challenges by adding business-facing tests that support the development team and in the future can help you accelerate your delivery.
