The global reach of your software could be stalled because of improper design or late detection of bugs. To release software to be used in more than one country successfully, you should try some tactics you might not usually employ. Consider these special approaches to keep a global mindset when testing.
I was recently reading about how Twitter got really popular in Japan. Among some of the reasons for its popularity was the fact that its feature set blended well with the intrinsic culture of Japan. Interestingly, when Twitter was launched in Japan, tweeting in the Japanese language required adding a space and a period at the end of the tweet so that it would be accepted by the system; this was a technical limitation.
The Japanese launch reminded me of one of the challenges I had to deal with when a software application I was testing was not installing on a Spanish-language operating system. Weighed down by traditional thinking, the Spanish language was assumed to be out of scope for tests as there was really no requirement for us to test for the Spanish market.
In another slip-up of a bug being handed over to a customer, I am reminded of a case in which a software application update for a German customer created a horrible mess when it changed the user interface language to French, obviously causing a huge backlash among the German customers.
Demystifying Global Software Design
In the first case, the root cause was the hard coding of the user name "administrator." The same word in Spanish is referred to as administrador, which the Spanish OS expected at the time of application install. In the second case, rather curiously, the build process erroneously led to French resource files being picked up instead of the German ones.
Both of these cases reflect elementary examples of how the global reach of your software could be stalled because of improper design and the lack of a timely detection of such issues. So, what constitutes a global software design?
The answer to this question can be understood by thinking about what would happen if the software were not globally designed. Yes, the above two examples give a perspective, but there is much more to it than meets the eye.
Let me explain a scenario I experienced while working with a technical support engineer of one of the products. This person was dealing with a customer from China who had the Chinese version of the product installed. The engineer, being from an English-speaking region, was well versed with the English version of the product. As a result, there was a good deal of difficulty in understanding the problem the customer was facing. This typical problem can be solved by an aspect of global software design called multilingual user interface, abbreviated as MUI; this allows the users to switch between languages at the run time.
Dealing with some languages, especially East Asian ones, becomes challenging in the context of computer software. Some languages contain thousands of characters in their repertoires, but a standard keyboard can only host a limited number of keys. Input method editors, or IMEs, make it viable to type in such languages. A globally designed software application would support flawless interaction with IMEs and also the processing of Unicode data by the applications.
Further nuances about global software design can be understood from the heuristic explained below.
Approaches to Build Global Thinking While Testing
The below text covers two aspects of building global thinking. The first aspect deals with the time of testing and the second aspect refers to the time of test planning.
In much the same way the climates of countries around the world vary, user behavior and expectations also change with the market. Thus, the mnemonic CLIMATE is a heuristic that also represents a means to build global thinking while testing. Consider the following examples and the questions you need to ask yourself.
Cultural awareness:
- What can I test regarding the date, time, number, currency, address, and paper-size format for the language under test?
- Does my application have a data representation where I can test the language sorting?
Localizability:
- Does the UI of the software application contain any strings that are in a non-native language?
- Are the UI strings externalized in a standard file format?
Input, Display, and Output:
- For East Asian languages such as Japanese, Chinese, and Korean, does the application under test support entering data using IMEs?
- Does the localized data show up without any distortions on the UI?
Multilingual User Interface (MUI):
- Does the application allow changing the language at the time of install or at the run time?
- Does the language fallback logic work if the underlying system language is not available in the application?
Association:
- At different times during performing globalization testing, it is apt to combine two or more facets and see if you can generate more test ideas. For example, combining "M" and "C" after the language of the application is changed during the run time could create questions about whether the application shows various cultural aspects like the date, time, and currency based on the newly selected language.
Translation:
- Does the translated text on the UI show up without any truncations?
- Is the context of translated text accurate with its position on the UI?
Encoding:
- Does the application support entering and display of multibyte localized data?
These examples represent some basic questions that could be applied at the outset while testing a global application.
Implementing Critical Questioning During Test Planning
In his book Product Strategy for High-Technology Companies: How to Achieve Growth, Competitive Advantage, and Increased Profits, Michael McGrath mentions that there are different ways to define global product strategies.
The healthcare.gov website is an example of a regional product strategy, meaning the application is designed to be accessed by one country or directly related countries. In other cases, the product features could evolve to cater to a different region’s market, which represents a product diversification strategy—such as Logitech designing specific mouse features to enter China’s market. In the case of mass-market products like Windows 8 OS, the product is designed once with wider considerations and caters to global markets.
One thing that is usually challenging for testers is being able to understand the business and product strategy for the application under test and being able to use it as an input to testing. More often, this information is missing from the tester's armory or is not demanded enough. In order to think globally, a tester would need to understand how the product or application under test is going to be accessed worldwide. In the absence of ready information, this can be done best by asking critical questions such as the following:
- Is my product going to be used only for one local market?
- Is it going to be sold in more countries than just the local market it was made for?
- Is it possible to customize the product to suit the needs of global markets?
- Is the product fully global and adaptable to any country without any design changes?
Widening your horizons beyond the local market and getting yourself to think globally while testing can only help enhance the prospects of your application being considered as truly viable worldwide.
Please share your thoughts about how to help testers think globally in the comments section below.
