We live in a world today where we can quickly make a call from our computer to people living on the other side of the world. Our applications can be used anywhere, even in places we have never heard of! With the 21st century, we have entered an era of great challenges around the internationalization of products. How can testing handle so many languages, given that support for a new language can be mandatory very quickly?

If you are not using model-based testing, you should definitely look into this technology. You can model your functionality to be tested at a higher level of abstraction than your application under test, and let an engine automatically generate your test cases for you. If you are already using model-based testing, you might be wondering:  » How can a model reflect the internationalization of my product?  » There is more than one solution to this problem, here I share one of the solutions that I think is the easiest.

The beauty of model-based testing is that with a high-level model, automated test generation can be done easily, and we can use this to tackle our multilingual challenge. When I model my application, I express the functionality at a higher level of abstraction using a « placeholder » concept . By this I mean that I don’t check for specific strings in my model, but instead describe for example: « Find in my login page, the names of form fields equivalent to « login » and « password »; in any target language » . I don’t check for the specific text « login » and « password » because it is only correct in English. I just leave the language issue to automation.

So, leaving this challenge to test execution automation, when I generate test cases for this example, I follow a pattern like this: In my login page, I need to check a form with the equivalent of « login » and « password ». I can now run this test once by replacing the wildcards (eg based on a mapping described in an Excel spreadsheet with the English equivalents) and generate the English version « find in my login page a form fields named « login » and « password » » . When I add another column for French, my test execution tool generates a test case with the same logic , but checking in my login page a form for « username » and « password ». Here, I let the test execution framework take care of the specific language, and my model is generic!

Now, some applications like TV decoders, web applications, etc. have menus or parts of menus that are only present with a specific country or language setting, but not with others. We can use well-known techniques in model-based testing: based on the previous language selection at the beginning of our flow, we block some branches of the flow and thus prevent tests from being generated for these settings. It is useful and interesting to know the exact coverage of each language you have obtained.

In conclusion, data abstraction is the key to internationalizing your product. In the long run, and for scalability reasons, it is better to maintain a generic model with decision-making based on the selected language, rather than a model per language. The bottom line is that the model is not necessarily the only place where you should think about automation – nesting automatic test generation and automatic test execution can also help increase the automation of the testing process. So use this trick in your modeling and solve your internationalization problem in a simple and scalable way.

Thanks for reading! Please comment !

Read more at: https://www.conformiq.com/category/blogs/

If you have a specific topic, please let me know!