Today's post is written by Jen Ford, Principal QA at Sonoma Partners.
The last blog post I wrote about this topic covered the “Who” and the “What” of planning out test data for mobile apps. Now, I will focus on the “Where”.
The “Where” – Where are your test users, and where are you?
As a tester, where you are located and where your test users are located, are integral components of mobile app testing. Like data security I mentioned in my previous post, this is another great place to look for defects. First let’s look at where your test users are. If you have a global implementation, differences such as language, currency, and time zones can cause instability in the app if not tested properly. While difference in language and currency are fairly noticeable in a mobile app, how data syncs to a back-end system in different time zones is more subtle.
The first step is to make sure the following questions get answered:
- What languages will this app support?
- What currencies will this app support?
- What time zones will the users be in?
When considering test cases for language, we will want to review the app in multiple languages. But there’s more to it than just that. Some test cases that are important to check include the following:
- Make sure that when entering special characters in a language other than English, they display properly in the app, and in the back-end system when data is synced.
- Make sure any text (field labels, instructions, demo modes) in the app display their special characters properly.
- Field and label length. In some languages, the translation of a word is significantly longer than its English counterpart, or the word can translate into a multiple word phrase. You will want to make sure these labels take up proper screen real estate in other languages, and don’t overlap other text on the app.
We have similar potential pitfalls with currency as we do language. Consider the following when writing test cases:
- Make sure that when entering currencies other than USD, they display properly in the app, and in the back-end system when data is synced.
- If the currency symbol is to be stored in the back-end system, make sure the correct one is associated to the value.
- Make sure any text (field labels, instructions, and demo modes, for example) in the app displays the proper currency symbol, and the proper punctuation. For example: in USD, we’d expect to see an amount like this: $1,000.00. In Japanese Yen, we should see it as this: ¥109,416.48.
- Field length. Similar to language, make sure that when you enter a currency amount, that you can enter a large number. Going back to the amount in Yen, that number gets large very quick, so ensuring that those large amounts (both positive and negative) can be entered and properly stored in the back-end system is crucial to the success of a mobile app implementation.
Time Zones can be tricky if you are only dealing with a few that are close, like just the continental United States. Not taking into account time zones when testing can cause various issues with display and with actual data. Birthdates can be off by a day, policy effective and cancellation dates can be incorrect, and the ramifications of these issues are significant. The good news is that you won’t need someone from every time zone to test if dates work across multiple time zones. You only need two: the one that you are currently in, and one additional time zone. If the test fails for the one additional time zone, it’s going to fail for all of them. Conversely, if it passes for one, it should pass in most scenarios (edge cases notwithstanding). Here are some examples of what should be tested with time zones:
- If someone is born on 1/1/1980, and this is logged into the app while in GMT, it should display as 1/1/1980, regardless of where the app is being accessed from in the world. A user accessing this data from a different time zone should not impact this date whatsoever.
- Effective and/or Cancellations dates. If you start an insurance policy, for example, your policy will have an effective date and time. If you start your policy on 5/1/2016 at 12:00 AM GMT, then this should display in CST as 4/30/2016 at 7:00 PM, since this is the exact same time.
Regardless of the time zones that the app will be distributed to, testing with two time zones that are far apart from each other is the easiest way to spot defects, because the dates could then show as being off by one day. I recommend whatever time zone you are currently in, and another one that has a 12 hour time difference.
The next important “Where” question, is where are you? Where are you physically located, and where are you going with this app? This deals with how your app connects to the internet, and how it should behave when you are offline. It is important that your app is able to handle changes in internet connectivity. If this is an app that people will be taking into areas with little to no connectivity (hospitals airplanes, etc.), gracefully handling the app being online vs. offline is important.
Here are some ways to test connectivity:
- Test app functions (browsing, entering data, map functionality), while connected to a wireless network.
- Test app functions (browsing, entering data, map functionality), while connected to a cellular network.
- Test app functions while offline.
So, those seem pretty obvious, but the interesting stuff happens when you transition between each of these connection methods. To do this correctly, I recommend taking a walk (yes, a physical walk) with the app. When testing an app at work, this is a typical process that I go through:
- Start in the office, connected to a wireless network.
- Start walking around the office, making sure functionality continues to work, and any syncing or storing of data to a back-end system functions properly. I’d also make sure that maps are showing as I expect them to, based on my location and what other data points should be showing.
- I’d walk out into the hallway, and wander around a bit. My wireless connection will drop and connect to a cellular network. I want to make sure the app gracefully handles the switch, and that data entry, data display, and data retrieval are not interrupted with an unnecessary error or alert.
- Then, I’d get into the elevator and watch my connection drop completely. Now I want to make sure that the app handles the switch to being offline. Does it display proper messaging, so that, as a user, I can visibly see that I’m offline? Does the app continue to work without crashing when submitting requests? Does any map functionality stop working and gracefully displays proper messaging to let the user know the map is not accessible (or display a stock image)? Does the app queue up requests that need to be synced to the back-end system, so that there is no data loss while working offline?
- After my elevator ride, I’d get off and resume my connection to the cellular network. Is the switch handled well? Does my app now indicate that I’m online? If data is expected to sync automatically, does this happen now that I’m back online?
- Then I return to my office, automatically reconnect to the wireless network, and resume testing. If I did not see any connection issues going from Wi-Fi to cellular, I wouldn’t expect to see any going from cellular to Wi-Fi, but if you’re walking that way, you might as well get some extra tests in.
Adding the “When” scenarios to your tests will start to broaden your scenarios and show you how this app will be working in real world scenarios. Enjoy the walkabout and prevent defects from entering your app once it’s live.