General Recommendation

Object-Oriented GUI Recognition method should be used whenever possible. If an object is completely supported by testing tool then wrapping functions (provided by the testing tool) should be used to interact with the object. If an object is partially supported by testing tool then object’s native methods and properties should be used when required.

If an object is completely not recognizable and not supported by testing tool then Optical Character Recognition (OCR) method should be used as workaround, if possible. For sending commands, keyboard shortcuts supported by the application could be used as workaround too. However, the workarounds noted above require sufficiently more investigation and programming efforts, producing bigger amount of the code at the end, and may still contain hard-coding and certain limitations that impacts reliability and robustness of automated testing.

Keyboard Shortcuts

 Most of GUI controls do handle keyboard events and have a short-cut command defined. That includes “Alt-<Char>” combinations for the buttons, window menu items, and some labels. Testing Tool is required to send the keyboard sequence within the context of the parent window.

Other controls while being focused do accept “Enter” or “Spacebar” keyboard commands usually as a default mouse click operation.

The main disadvantage of this method is in “blind” interaction: the presence and availability of target GUI control is not verified, and in case of fail test execution falls into uncertainty making test results unreliable.

Complex action controls, like combo-box still do accept keyboard commands but using them without the visual feedback is barely possible due to hard-coded high-maintenance implementation.

Mouse clicks combined with Text-Based Recognition

 Even if the child object is not recognized by a testing tool the visible text could be still retrieved from the parent window. Knowing location of a particular text allows pointing mouse cursor and sending mouse click events that will be forwarded by the window into its child located at the click point.

Examples.

If text input box has a prompt label left to it then clicking on the “right-to-prompt” area will bring the focus to the input box. Then keyboard sequence could be send to the parent window which will forward it to the input box.

Clicking on the label text within a checkbox or radio-group will select the labeled option.

The main disadvantages of this method are hard-coded implementation and low robustness of test execution. It also features high maintenance cost.

Verification Based on Text Analysis and Comparison

 When retrieval of separate values displayed on the screen is not possible the whole screen dump could be taken and saved into text file. After the manual verification such a file could be used as expected result in automated text file comparison.

The main disadvantage of this method is the level of maintenance efforts on managing expected result files with the higher impact the more checkpoints of this type.

Additional issue is based on the screen content: if it contains non-valuable dynamic elements (like date-time stamps, etc.) those should be programmatically cleaned or verification will be always failed.