How to Think Globally about Software Testing


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.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.