So , what is the easy way to test that keyboard layouts for specific languages work? Especially if you are not conversant in languages at all.
I’m being more specific to mobile here and Bluetooth, but this question applies equally to wired keyboards and desktops in general. And of course layout variations per language too.
Most products will localise (internationalise) the UI, that’s not my question, I’m talking about input fields processing. It’s a crutch in that for me I’m not remotely conversant in anything, perhaps a tiny bit of German , but it’s the only language I might be able to read. However, French , is probably the best language to be covering if you have a lot of French customers, which we do. Portuguese and a few others come to mind, but generally it’s the need to support at least 4 other languages well. I would love to pay someone to test our app, but since it’s a mobile app, that’s just a bit unrealistic.
Should I just go find Apple any non-apple French keyboards, but where do I really start in terms of knowing enough about special characters to know which special characters matter most? Which ones are corner cases; and for example which are likely to make sense in for example an address input form which has to be input and then later on displayed back and be sure the back end did not bust anything? /Edit: I’m not testing “my” form, really. I’m wanting to test like notepad.exe or apple-notes works correctly while our app is running and echoing the keys typed and passing them onto the app that is in focus on the desktop.
I’m keen to just buy a few French keyboards, and see what comes out, but should I and how do I know what variations of French or German etc. layouts perhaps exist? I don’t want to get a Polish keyboard for example and not even know how to use it and end up gathering dust.
Can you somehow reach the input process via an API? Then you could throw all UTF characters into it.
I guess at best in batches to have a compromise between performance finding the one failing character.
Once a failure occurs you could you could split the batches and process each character separately.
I’m not very much into UTF, maybe you can identify and separate groups of characters which make sense and which not. I would also be interested in what happens with “bad” characters. Sooner or later it may get entered.
At least on PCs I do not think you need dedicated hardware. You should be able to change the keyboard language on your OS.
And there are maybe also virtual keyboards.
Windows has both.
@sebastian_solidwork I could just throw random characters - but unlike 90% of testers and scenarios here, our app has actual keyboard key mapping support and mobile phones have on-screen keyboards too. So I really have to plug in a real keyboard. So just putting stuff into a form would not cover any of that code path in a way that a native language user would care about, and I’m pretty sure is not going to show up problems a human would encounter.
I’m not testing the form saving or loading or data validation, the form is not under test. I’m testing the ability to type characters and have them appear correctly. Sorry was not specific about that.
Wouldn’t it be enough to test if your app accepts the characters specific for a language? Like the umlauts for German? Add a few special characters and qwerty, if these are accepted? Or do you really need to make sure that the app is running in the correct environment? Because then you would have to change the system localization (ie switch system language to German) and type some characters - when the keyboard is registered as a German one (doesn’t matter what a keyboard it actually is), “qwerty” would for example become “qwertz”.
Now I understand your situation better. This is different from what I had in mind.
So it sounds like you have to do with key codes.
By privately playing around with keyboards I know a bit, but please evaluate it yourself
I think you are having to issues:
What characters / scan codes should be send over all (which are on a keyboard)?
Here are different keyboards with that information: https://kbdlayout.info
e.g. French (Standard, AZERTY) - look at Downloads for data
How to send them to your application?
I suggest you to ask the developers for more technical details what is happening here. Once you know more about the basics, you should be able to get ideas where/how to slip in.
They physical keyboard layout is one thing, the OS language keyboard settings another.
Idea: Can someone build you a hardware keyboard simulator (or do exists some)? By which you can send signals from computer to the test device, like a real keyboard would do it.
I don’t know if it would be relevant, but when I was learning Japanese the virtual keyboard had functionality where I would type in hiragana (the letters/phonetic symbols) and suggestions would be made of the kanji (the symbol representing the word, approximately) I wanted, which I could then select and that would be typed. Again, not sure if Japanese as a language or whatever process was going on behind the scenes there is relevant to your case.
Well, I have gotten some good pointers to look out for. As any this will be an ongoing project because I not only need to send characters in both directions between two computers but I also need to involve a cell phone. And the main thing was to get some tips from people for how to understand German Japanese and other layouts, so that has helped with the homework. The engineer who is supposed to have done the keyboard input automation code on one side is overloaded, but some ideas have been very helpful as things to investigate once we can get the input simulated.
Would it help to install different language keyboards on your device? Then you switch the keyboard language and type any key that looks special - no language knowledge needed.
I have never found the need to understand a language for typing and layout tests.
Yeah, that’s the route I am going to follow as a start. I had a chat with my team lead yesterday, some bugs have crept in, over time, and all because automating these has been hard, and manually testing requires loads of patience, not to mention confusion.