If you’re ever handed a testing assignment that includes testing an application or website in a language you don't understand, don’t panic.  I’ve had to do this several times, and I’ve learned a few things about what you can effectively test without fluency.

The Good News

In most cases where you’re testing an application in a different language, you probably know something about it—if it’s not an interface you’ve already tested, it will have workflows similar to applications you’ve already tested—so you can apply normal tests to the interface to look for where things break.

If your employers or clients know the limit of your abilities up front, you won’t be responsible for checking spelling or translations, such as whether the Submit button has been deciphered as Yield. The copywriters or the translators bear the blame for the screenshots that end up on foreign humor sites.

Here are a few things you can always test—regardless of whether you speak the language.

Check the Layout

Ensure that the layout of the website or application does not have any obvious errors, such as characters overlapping each other or misalignment of headings and text. This happens sometimes in localization, where the site was designed for English but the localized version uses another character set.

Recheck Functionality

You can test any form using basic tests, such as trying to enter too much data in an edit box, attempting to submit without filling out all required fields, and double-clicking the buttons. In most cases, you’ll already have a passing familiarity with the application in your own language and will understand its goals and purpose and how to try to thwart them.

As you do so, make use of the online translator you prefer to make sure that the error messages match up as much as possible with the failure you elicited.

Checking the Copy

You might have access to the copy deck that includes the translated text in the application. In some cases, this only includes labels for controls. For several projects I worked on, I got a complete copy deck and I could do some basic checking.

On one project, I was testing the translation of training videos and their interfaces into French and Spanish. I could read along with the copy while the audio played and listen to see if the audio matched the copy. Although I could not speak French and my Spanish is limited, I knew the sounds enough to confirm the vocal talent read the same script.

In another project, I had to test a different training program and interface in Russian, which uses the Cyrillic alphabet. I used the copy deck to validate the copy on the website to make sure all the words in the copy deck appeared. I did this by copying sentences from the copy deck to the system clipboard and then using the web browser’s Find feature to search for them. This way, I could ensure the copy appeared in order as expected.

Even if you don’t have a copy deck, you can use Google Translate or other free online services to spot check the interface. For example, you want to make sure that the label for the user name field is reasonably similar to “user name.” You won’t be responsible for verifying the idiomatic appropriateness of the label, but you’ll know whether it’s close. In some cases, this might be your only insight into the edit boxes and what you should enter in them.

Reviewing for Inconsistencies

You can review the copy at a very high nontextual level for inconsistencies. If you recognize the alphabet, you can tell if sentences are beginning with capital letters. You can check formatting. You can just go with your well-developed sense of right and wrong.

For example, when checking the Russian copy, I spotted a couple of inconsistencies. The translation service split up the copy and had different translators work on different parts of the copy. As a result, the website initially used both “quotation marks” and <<double angle brackets>> to mark quotations because Russian text allows both—but it would be inconsistent in a single work to use both. You might see a similar problem in Spanish if an upside down question mark (¿) were used at the beginning of one question and not for another.

In another case, the translating service split a long table between translators and included the table heading for each split. When they consolidated the result, the copy deck and then the website included multiple tables with the same headings following immediately after one another instead of a single table.

Use the Alphabet

Most foreign languages have extra characters with accents or umlauts. Some use entirely different alphabets. When testing an application in a different language, use that alphabet when you enter the data to test not only whether the application or website can process them, but also whether it presents that information back to the user correctly. That is, make sure the member name Günter displays correctly in static text and in the Edit Member Name edit box.

Knowing trivia about the alphabet can help you find other obscure errors. When testing chemical modeling software localized for Germany, I learned that the German eszett character (ß) is sometimes expressed in lower case as two characters (ss). Knowing this, I inserted it in a number of fields as part of boundary analysis. In cases where the interface allowed forty characters but normalized the data to lowercase, including an uppercase eszett in the forty characters triggered an error. Another example comes from Medium.com, where they discovered an issue that occurred when someone tried to type a character in the Polish alphabet.

So make sure that you test with the alphabet appropriate to the application language and not just the default keyboard language of your test machine. Another term for this is internationalization, or i18n: making sure the software can process other languages as input.

Spot the English

Even if you don’t speak the language of the application, you’ll know how to spot your own language, so search through the application or website for instances of untranslated text. Make sure that boilerplate pages, copyright notices, mouse-over text on images and fields, and error messages display translated. Also look at text inside images.

Identify these locations and share them with the team. Your stakeholders might decide not to translate all the text, but they should make that decision and not discover the oversight later. This is commonly known as localization: making sure that when the text is translated, it is completely and consistently translated.

Conclusion

The next time you have to test an application that’s in a language you don’t understand, be confident. You know enough about testing to get started, and you might even know enough about the application to cover basic functionality. And although you cannot catch every nuance of the interface and its text, you might actually find yourself learning something about the language itself.

Желаем удачи—good luck!