Champion Level 3Okay, how about giving us an example of how this would work. I'm interested to see how you would have "approved source target text" without setting up baselines.
Sorry for the delay in replying Marsha
As an example, let say you have a receipt from a store. That receipt has some pictures/logos, numbers and texts.
That same receipt has to be translated into 40 different languages.
You have the approved target translated word by word source. All you need to do is to check if there is any clipping, truncation, hyphenation and also checking whether the translated text does match with your approved translated word by word source.
We need to do this for all languages, in my example 40.
The receipt itself might slightly change during any period due to customisation but the text contents are still the same. Perhaps just moving positions, etc. Therefore it would be a daunting task if every time you have any minor change or any re-organisation of text then you have to generate baseline library images for 40 languages.
It would be good if TestComplete can nominate an area in the picture and detect any text displays there and we can get the actual text displayed in the UI for comparing it against target source.
Champion Level 3I agree. I can view 40 different screens a lot quicker for anomalies than the testing is worth. I would say automate the test for check that the stored text is correct and don't automate the "look and feel" tests.
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.
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.
Champion Level 3See, that's what I said way up there ^ but evidently the test is to make sure it displays on the screen properly and isn't getting cut off or whatever and the text value won't give that.
Hrm... that may be better handled, then, with checking things like height, width, etc. properties of the containing object.
Another possibility... how is the text rendered to the screen? Is it HTML code that could be parsed for things like font size, CSS styles, etc?
Image comparisons may be the only way to do that... and here's where I say ditch these kinds of comparisons for automated testing. Honestly, as has been pointed out, creating and maintaining image comparisons for 40 different languages on any number of device resolutions, etc., is going to be a LOT of time and resource... meanwhile, a human doing manual testing of UI "look and feel" can do the same kind of processing probably a LOT faster than the time it would take to code all these contingencies.
Yes, ANYTHING can be automated as a test... but SHOULD it be? Will there be sufficient ROI for the effort spent do code and maintain the types of comparisons necessary for this test (and, BTW, this would be a problem regardless of tool)? Or is this a test case that might be best left for manual verification or unit testing on the development end? Obviously, I can't make that decision for the OP, but it is part of my consideration matrix when determining what to automate.
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 :(
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.
