Localized software QA/testing is, sadly, a step that tends to be overlooked, executed poorly or ignored altogether by developers, for cost reasons or lack of understanding of the process. Yet, with proper organization and planning, it is possible to keep costs at a reasonable level without hurting the final quality of your products.
An approach that can lead to cheaper localization QA is to split linguistic and functional testing. In other words, you will want your native-speaking testers to focus solely on parts where their linguistic knowledge is strictly needed.
Before I go further, let me clarify one thing. Ideally, if budget allows, you will want target language experts to check everything. A final eye never hurts even if the text was professionally translated by a professional and proofread by a second person. Even a seasoned proofreader can let the occasional typo slip through.
Why split testing tasks?
To simplify, the main goal of linguistic testing/QA is to make sure your localized software or video game works in context (mostly a linguistic task) and displays as it should (that would rather be functional testing). If you pick up some spelling and grammatical issues along the way, great, but in theory that should have happened during proofreading, and those would be rather minor issues as long as they’re few and far between.
The point here is that not everything absolutely needs to be checked in context. Strings that are self-explanatory or don’t rely on context (more on this later) should already be good to go. They still need to be tested to make sure they do display, and correctly so. But since the text doesn’t rely on context, you shouldn’t find any mistranslations/ambiguous phrasing here. So, in theory (again, that’s assuming your translator/proofreader team did their job!), functional testing is all you need here. This can be done in-house, or by essentially anybody able to follow instructions carefully, regardless of the languages that person can speak – this is where you can do things cheaper without taking major risks.
Parts that rely on context, on the other hand, must absolutely be checked by a professional tester. A mistake many developers make is to hire the cheapest native speaker they find for the task, regardless of their experience in localization testing, or in the language industry for that matter. Remember, testing is your last chance to eliminate critical issues. You do need an experienced tester with an eye for details and a perfect command of the target language. Most people don’t have a good command of their native language – spend 5 minutes on any online forum if you need to be convinced. That’s the one time you can’t allow yourself to be cheap.
So, what does need linguistic testing?
Buttons, labels, menus, essentially anything that can be interpreted differently based on the context. UI and menu items in particular are critical because they directly affect usability. A typo in an error message is embarrassing, but it doesn’t prevent users from using your product as intended. Mistranslated buttons and labels, however, can seriously hurt user experience.
What you need to ask your linguistic tester here is to check the interface, use the different features and make sure button names, labels, etc. are easy to understand and match the actions they’re linked to. Put the focus on usability. If a translated string is not completely wrong, but not clear as it is, change it. That’s the sort of improvements you should aim for.
That’s about it for software. If you are developing a video game, you may want to check other elements besides UI/menus. Dialogs are the most common type of text that is heavily context-dependent. Even if you more or less know who speaks to whom at what point on the game, seeing the scene unfold in-game may help you notice certain details. An example: a dialog occurs between 2 characters, and in the file you’re translating, it seems they’re the only 2 people present. But during testing, you realize a 3rd character is with them. In this context, in French, there may be cases where you would need to switch from singular informal “you” (“tu”) to its plural counterpart (“vous”), which would affect the rest of the sentence.
Again, planning will help you reduce costs here. Once thing I’ve seen developers do is to create scripts that allow testers to see all dialogs of a game in context and in sequence (=without playing at all). This way, you don’t get charged extra for the “idle” time spent playing between two scenes. Focus is the key.
What may only need functional testing (“self-explanatory strings”)
Descriptions, system messages, and in general any unambiguous string that would definitely translate the same wherever you use it. It can be error messages (“File not found.”) in software, or a character biography in a video game (assuming the string leaves no uncertainty about whose biography it is). If a string doesn’t need context or does provide it, and was properly translated/proofread, functional testing is all you should need. You’ll focus on overflows, garbled characters, hard-coded source strings, etc. The usual lot.
It’s also worth noting that pseudo-localization, another overlooked part of the localization process, can help prevent most of implementation issues beforehand.
Cheaper testing & QA without sacrificing quality is possible… with the right team
As you will have noticed, I stressed the importance of having a team of professionals working for you: your translators, proofreaders and linguistic testers all need to be experienced and reliable to ensure the quality of your final product. Hiring a team of experts might sound more expensive at first, but it is a prerequisite if you are to implement the process I described above. See it as a small upfront investment that will allow you to make significant savings down the road.