The generation of test cases for a multilingual feature that serves different user types would be approached in the following ways:
I am doing my testing in a web app feature that is multilingual and serves various user types. How do you want to be the approach for test case generation providing full coverage?
I would say it’s depending on your risks. If high, then MC/DC or multiple condition should be applied.
For our e-commerce website checkout flow testing, I have chosen a set of several countries that are exercising different languages, payment methods, VAT rates, currencies… Made a table to have all the main characteristics exercised at least once in the suite. And it repeats it entirely for a few given scenarios : customer as a guest, customer creates an account, existing account… It’s part of our regression tests and so far it works pretty well !
I hope this helps.
Similar to Rod’s view, what are the risks. User types is likely a bit different from the specific multiple multiple language risk.
Consider the risks associate with that and add specific tests for support of multiple languages.
Full coverage sort of goes against testing thinking as it adds loads of waste. An old example was cross browser testing when testers were running all tests against all browsers in a catch all attempt when what they really should have done is look at the specific risks of the different browsers and create specific tests for those cross browser risks.
It’s generally a given these days that most sites have multiple language options, I use it to remind people that I am tester and not a proof reader, copy editor or cunning linguist looking for grammar or spelling mistakes is not a focus of my job. I’ll naturally pick up on these in my first language quite a lot and so will the many other eyes on the product but I’m not qualified to be that linguist, I’ll flag the risk and then if needs be get a language specialist to cover that risk.
If it works in primary language what are the actual risks with other languages?
A lot of languages for example follow the same patterns, test a couple of these and you have them covered. It used to be that character sets was an issue with a single character in one language takes twice as much space in memory so you would want to test at least one of those, some language read right to left and that changes overflow logic potentially, create a test for that. Equivalence partitioning of language might be something to apply here to reduce your tests needed.
I’ll add a precision here after reading @andrewkelly2555
You want to test that your translation is present, not the translation itself.
Like : “the page is displayed in the french translation” is a test case that your page can be switched in different languages. As a tester I’m not testing the content of the french translation, but that technically, french translation can be applied.
I’d echo that view. We have a configuration option in the url where we can see a “translated” UI that is built from a language specific configuration. Lucklily our products are mainly graphic and less wordy but translations are still necessary, So we have 1 configuration where all the “translatable” text in in reverse. So can easily determine if the text is translatable and thats all we need to check. The rest is in config files, so the appropriate language expert updates those files. If the translation is incorrect, update the text in the file.