Blog

By: Nancy Kelln

The complexity of translation testing is often overlooked. In past projects I’ve heard – “All we need to do is check that everything is in French and there is no missing content on any of the pages”. Ha! If only it were that easy! There are many aspects to consider. On my most recent project as I went through all the different areas and made a list of each I noticed I had a list of five letters. P I E S S to be exact. With a little shuffling of the letters I came up with SPIES, a mnemonic for testing internationalization. I’m sure these five areas don’t cover all contexts one may need to do for internationalization testing, but I think its a great start.

SPIES Mnemonic

S – Special Characters

Languages like French, German and Spanish contain different characters. In my experience not all applications can handle the various special characters that can make up another language. For a previous project we had a spreadsheet that listed all the special characters in French then tested to make sure our fields could handle these characters. Having an international keyboard designed for your language makes this task easier. Since this testing can be fairly lengthy and boring look into automation to help out. Don’t forget to include special punctuation as well!

P – Pages & Content

In my experience this is typically main focus of all translation testing. But only focusing on this area can get a project into trouble. The testing of Pages and Content is two-fold. The first part checks that all the pages display in the new language. The second part checks that the content (or meaning) of the message is correct. These can both be rolled into one check by enlisting the help of someone fluent in the language you are testing in. To effectively test content you will need to enlist the help of someone who understands both the application and the language you are testing in.

I – Integrations

While the scope of the project may be to only change one application, it is rare that applications stand alone and do not connect with other systems. Our scope may not include internalization changes to those other systems, but can these connecting systems support changes we make on the system that is in scope? We need to consider the other systems we are connecting with. Our changes could cause negative impacts when an integrating system receives characters it isn’t prepared to handle. I once worked on a system that wrongly assumed the comma that French uses to represent fractions of money as a thousands delimiter! Although the receivers of the incorrect cheques were happy our business wasn’t exactly thrilled to be paying 1000x more than the proper amount. When dealing with other connecting systems consider special characters, punctuation, date, time, time zone and decimal formats.

E – Error & Warning Messages

I’ve separated error and warning messages into a separate topic from Pages & Content because I’ve seen the effort of testing message translation can be underestimated. It can be difficult to check that every single error and warning message has been translated. First off there are numerous error and warning messages in a system and getting to each one can be very time consuming. Often times we don’t have the correct conditions to generate all types of error and warning messages. Additionally, unless we have comprehensive documentation detailing every message in the system we may not even know what or where they all are. When approaching message translation testing consider ways to access the messages that do not require you to access the application from the user interface. Review source code for areas where messages are output to end user, compare content files between the original language and the translated language to see that translations have been made, or consider automation. If there is no way to access the system from the back end, focus on the most common messages via the user interface. Finally, don’t overlook logging files or back end error repositories. If translation is required for the entire product it may be a requirement that administrative and support logs be changed as well.

S – Special Formats

Dates, times, time zones, numbers and decimal formats may be different with a translated language. Can your system handle dates as DD-MM-YY and MM-DD-YY? Is 24-hour notation and the 12-hour AM/PM clock both acceptable as time formats? Are monetary values calculated correctly when a decimal point is replaced with a comma or is the system assuming $1,00 is equal to $1,000? Can the timezone be changed? Can the system handle daylight savings? Can daylight savings be turned off? Depending on where the application will be used there could be a number of considerations for special format testing. Investigate the rules for date, time, currency, decimal notation and daylight savings for your region. Often this is one of the areas the most interesting bugs can be found.

So the next time you are handling an International Testing Mission call upon your SPIES. Not only will SPIES help focus your testing it should also help explain the complexities of testing translations to those who may say, “All we need to do is check that all the pages are in language X!”

---

Nancy Kelln is an independent consultant with 12 years of diverse experience within the IT industry.  Nancy is motivated by working with teams who are implementing or enhancing their testing practices; providing adaptive testing approaches in both agile and traditional testing teams. She has coached test teams in various environments and facilitated numerous local and international workshops and presentations. She is an active member of the Calgary Software Quality Discussion Group, Association for Software Testing and the Software Test Professionals organization and has co-founded the Calgary Perspectives on Software Testing Workshop (POST) with Lynn McKee. You can reach Nancy online at www.unimaginedtesting.ca or on Twitter @nkelln.