Identifying objects using MSAA

Hi,

Recently I benefited from MSAA support in TestComplete and like to share with you the same.

The problem came up when I intended to automate few of the UI (windows application) controls. I tried this in a system where I have TestComplete 7.5 installed on Windows XP.

To be clearer on the issue, TestComplete shows the entire application as a single window (inside its object browser tree) without any child windows/controls. When I try to record the actions on the controls like text box and radio button, all were recorded as actions with respect to window co-ordinates and not with actual controls. Surely script will be having issues when relied on these co-ordinate related actions.

I am clear that TestComplete is not recognized or the application’s controls were not open enough to automate them.

This intuited to try MSAA mechanism and as expected, succeeded in automating all the controls on the above mentioned application with the help of exact object identification.

My questions on this issue:

1. What is MSAA?
2. How the TestComplete able to identify individual controls after configuring MSAA?
3. Why this feature is not available by default?

What is MSAA?

According to Wikipedia “Microsoft Active Accessibility (MSAA) is an API for user interface accessibility, designed to help Assistive Technology (AT) products interact with standard and custom user interface (UI) elements of an application (or the operating system), as well as to access, identify, and manipulate an application’s UI elements”.

Simply we can access UI controls and its properties when interfaced through MSAA mechanism.

TestComplete uses this technology to get access to UI control’s properties and methods which are not readily exposed. This is done with help of AUT window’s class name.  MSAA configuration can be done in the project properties as below in TestComplete,

1. Select ‘Project properties -> Open applications -> MSAA’.
2. In the ‘list of accepted windows’ list view, add new item and specify the windows class name whose child controls are not recognized.
3. Save the changes.

How the TestComplete able to identify individual controls after configuring MSAA?

Basically when above configuration is done, TestComplete will query for the UI control details using MSAA mechanism and populate them in the object browser.

And remember, TestComplete will able to identify the controls only if the object/window of AUT implements the IAccessible interface.

Why this feature is not available by default?

Just to avoid complexity, this feature is not available by default. If it is enabled then TestComplete object browser will be loaded with lot of windows and controls which we may not be using always which in turn affects system/execution performance. I guess this will be the reason behind limiting the MSAA configuration to projects and not even project suites.

To summarize, if you face any problem where any of the AUT UI controls were not recognized in TestComplete try to check the below items:

1. AUT is a windows application and TestComplete identifies only main window which has child windows/controls.
2. In the object tree, the last identified window has a wndclass property.
3. The Application/Window object implemented IAccessible interface.

Then MSAA should help you in automating these controls…

MSAA updates

MSAA has a new partner called UIA (Microsoft User Interface Automation) which is more advanced in querying the properties and methods.

According to Wikipedia, “UIA is similar to MSAA in that it provides a means for exposing and collecting information about user interface elements and controls to support user interface accessibility and software test automation. However, UIA is a newer technology that provides a much richer object model than MSAA, and is compatible with both Win32 and the .NET Framework. UIA is designed so that it can be supported across platforms other than Microsoft Windows. For controls and frameworks written from scratch, UIA is recommended today. While MSAA is handy for relatively simple controls, the technology doesn’t support the complexity of modern user interfaces.”

For more details on working with TestComplete and MSAA follow the link — http://smartbear.com/support/viewarticle/11501/

References: Wikipedia.org

Thanks & Regards,

Giri Prasad

Believe!!! There are 101 ways to automate…

Data handling support in TestComplete – Part 1

Hi All,

In testing/automation we deal with different types of ‘Data’ say Test data, Expected data, Configuration data and execution data, etc,. The dependability on test data changes based on the framework chosen for automating the AUT. Data Driven Testing has more dependability with the Test data and Expected data than other approaches. Overall we need a good mechanism to store, configure, and use them in to the scripts to effective automation.

So when I ask data handling for Automation, I might get answers from 2 categories.

1. Using scripting language
2. Using Automation tool

Since most of the script languages have a programmatic approach (Initialize, Use and Destroy) in handling the data and mostly they are not persistent across executions, we will move and concentrate to second option and get clarify on the support provided from tool perspective.

We must understand that data handling plays a key role in determining the success of a test automation implementation before moving to handle it. A complete analysis of our data handing requirement must be done before choosing an approach.

TestComplete supports DDT and provides various options to store data through it. Some of them are,

1. ProjectSuite/Project variables
2. Stores
3. Using Data Storages
4. Storages Object

I am going to consider the following criteria for each facility:

a.      Scope

b.      Easy accessible

c.      Adapting to change

1. Project Suite / Project variables:

The project suite and project items created using the TestComplete was designed to store data in them apart from project related properties. To use it, we have a choice of few available data types (String, Integer, Double, Boolean, Object, Table) and give a meaningful variable name to it. From the scope perspective, these Project suite/Project variables can be classified as ‘Persistent’ and ‘Temporary’.

Simply, Persistent variables hold their value between the test executions whereas Temporary variables will not. And Persistent variables have some advantage over distributed automation where we can have separate value for each remote host thru ‘Local value’. Also when your script is accessing and updating both persistent and temporary variables, in the next execution persistent variable will have the updated one whereas the temporary will hold its default value.

The properties of these variables are,

Name – Name of the variable (should follow basic naming convention).

Type – Any one data type to choose from – [String, Integer, Double, Boolean]. The temporary variables can also be of type Object and Table

Default value – The default value if any for the variable.

Local value – This is available only for persistent variables.  Local value to be used for remote host on distributed execution

Description – Summary to explain the variable usage

Scope:

Global to the declared item. As per the name says the project suite variables can be accessed across the project inside the suite and project variables are accessible across the scripts inside the project

Adapting to change:

Yes. We can modify these variables anytime during the execution inside the scripts and always available to change. Mostly these can be used where we need to same set of information across script unit and where value set by one script need to be accessed by another.

Easy accessible:

Syntax:

Project.Variables.<variable name>

ProjectSuite.Variables.<variable name>

As mentioned above can be accessed anywhere to ‘set’ or to ‘get’ the values. The TestComplete will give you code snippets for the defined variables.

Using Stores and data sources will be continued in next post…

Hope there are 101 ways to Automate !!!

Thanks & Regards,

Giri Prasad