This is more fallout from me digging through my mailbox and deleting old emails. I found this from our start of testing for OneNote 2010, sent from the tester who was our international test coordinator.
To ensure language neutral automation, use Utilities.GetRandomString() when placing random text on the OneNote page or any location.
This function returns a random string of different languages depending on the machine configuration. For example, if Japanese and Arabic are available on your machine, then random strings of all three languages [assumes you are running on an English machine – John] will be returned. This function is a wrapper for the string generator functions that …[ a shared team in the Office organization, “Global Experience” – John] provides.
You can use this function this way:
String text = Utilities.GetRandomString();
So this helps with getting legitimate and varied text strings to use for the machine being tested. Without this type of functionality, I might choose to either hard code a single string to use each time the script runs. A limitation with this approach is the string may or may not reflect a type the user would actually use. In this example, if Japanese and Arabic languages are installed on the machine, and I chose an English string, the test, from a user point of view, is not as realistic as a string that would use letters and characters from each of the installed languages.
Alternately, I could create strings from each language Office supports. This means I would need to detect the languages installed, and then use an appropriate string from my list. The disadvantage here is that my strings are still hard coded, and once they get used once, the same code path gets exercised each time through. I would also need to detect multiple languages and concatenate my strings to cover all installed languages.
So this method saves me some time and gets into exploratory testing a tiny little bit. Each time the script is run, a different string will be used, and the characters will be in a different order. This can help uncover subtle bugs, and that’s what I want it to help do.
And since we log all our test steps, if a particular string does cause a problem, we have it available to help debug and test any potential fix. Now that we know a given string caused an error, we can archive it and use it in tests in the future. (An implementation detail here is that we also log the Random seed the system is using, so we can run the exact same test if needed). Little tweaks like this that can increase code or international coverage very cheaply are always welcome to a test organization.
Questions, comments, concerns and criticisms always welcome,