I'm not familiar with mobile testing but, if the interface between TC and your mobile app is similar, the way I'd do it in a desktop or web application is look for the property that contains the text in the object in the application.
Say, for example, in a web application I have a textbox that contains the receipt text. That textbox would have a property called Text or wText or contentText which would contain the plain-text version of what I see on screen (no fonts, formatting, etc). I'd build a baseline of a simple text file (Stores -> Files) for each language baseline and then do a check of that property to the contents of the associated text file and look for differences.
Thanks Robert and Marsha for your information.
Unfortunately in native mobile app we don't have that.
The text that in the property is the text that developer puts in. The mobile operating systems then can render that based on screen sizes and other factors (such as text size, zoom mode, etc.) and displays the text in the UI as truncated/hyphenated, or even clipped.
So we need to have facility that behaves like OCR to get the text that you see in the UI.
Human will slow down significantly when dealing with 20,000+ images from 40+ different languages :(
Hi,
Pretty challenging task I would say... Great that I am not responsible for its solution and that solution is not required for yesterday... :)
Well, it looks like that you need to do two things:
a) Check that displayed text corresponds to the given configuration (locale); and
b) Check that text is properly displayed.
Point a) seems to be an easy one that can be implemented via the simple text checkpoint (or NameMapping configuration). And yes, it will be required to have the expected baseline for every language verified. (Though this may be generalized in code.)
Point b), on the other hand, is not clear enough as it does not provide a requirements of what must be considered to be a "properly displayed text". Mainly: what to do if the text is long enough and does not fit in the default control layout? Must the text be truncated? Just truncated (like it is usually done on receipts) or include dots at the end or somewhere in the middle? Or control must be dynamically enlarged to display the whole text? If the text is truncated, does that mean that control contains complete and abbreviated version of the text in its properties? Or control contains just abbreviated text version?
Depending on the answers on the above questions, this or that testing approach can be adopted. Most probably, the approach will be based on image comparison anyway, but the details and convenience of use may differ.
Champion Level 3What you might do for the text display tests is automate the ones that are likely to fail and do the rest manually. For instance, if the German layout has long words that might be truncated, then keep the screenshots for that one, or for Portuguese where there are many diacritical marks that might not be displayed properly.
There is an OCR object (https://support.smartbear.com/testcomplete/docs/testing-with/advanced/ocr/index.html) in TestComplete. However, I don't think it's going to do what you want. You are looking to make sure that the rendering of the text shows up properly on the screen. Using the OCR object will only retrieve the text. At this point, you're left with either relegating the particular tests to manual visual checks or using image comparisons.
