Combine automation technologies working with complicated desktop applications

Author: Alfonso Alarcón

This is a reality for automated testing engineers! This is the fact! In some occasions, it is practically impossible to generate functional testing on the user interface (UI) of some desktop applications.

Normally, the reason is that the desktop application is based on a code that is written in languages that are not recognized by spy tools or the recognition tool of the selected automation technology. This is very usual in legacy code that is created far of actual technologies.

The situation is more tragic when tools that are in principle powerful, such as the Coded UI Test tool of Visual Studio or HP UFT (to mention just two examples), fail!! In summary, it is a catastrophic situation for automated testing engineer especially when UI testing is essential and required by QA. What should you do? Fortunately, there are solutions.

The most logical solution is to combine different automation technologies (hybridize). I suggest using as the basis a solution of Visual Studio (a console project is enough) and over it work on other technologies. I mention two:

  • AutoIT: Autoit ( is a freeware software to provide automated testing on windows GUI.  You can work with the method of the class AutoItX3Lib. To do it you must download and install AutoIt from and add the reference of AutoItX3Lib to the solution. Please, also read about
  • White: It is a very interesting solution to extend the functionalities of Visual Studio to provide automation testing. It must be added via nuget:

It is noteworthy that it is not required any payment version of Visual Studio. With Visual Studio Express or Community versions is enough. In this scenario, you can provide a reliable automation without money expenses.

But possible your company desires to expend a lot of money in automation testing in this case I recommend Ranorex ( This is a powerful and complete tool that can provide work on web and GUI, and also in mobiles devices in both android and iOS. My suggestion is to combine Ranorex with Visual Studio (again combine technologies!) for a definite automated testing experience.

Finally, in an ending case Microsoft indicates an extension of the of the Code UI test tool to provide automated solutions where the coded UI tool does not arrive. But this solution is only for heroic automated testing engineers! I provide the next URLs:

In conclusion, there is always a hope to automate an inaccessible UI! And remember that the best solution is always combining different automated testing technologies.



Strategy to get automated testing without recording actions

Author: Alfonso Alarcón

Many times the usual work environment in large automated testing projects is under a continuous integrated development process. This implies that both development and automated testing processes are done in parallel.  In this scenario the most common problems are related with test cases that fail as a consequence of changes in the functionality (by part of developers) and not as a consequence of finding bugs in this functionality (that is the final purpose). For this reason providing a good treatment and maintenance of controls (different structures that conforms the functionalities of an application or web such as comboboxes, menubars, tablegrids, buttons, winedits, among others) is the key point.

The most extended way of working (and the easiest) in automated testing is recording actions. All the specialized software in this field such as Visual Studio, HP UFT, Ranorex Studio, SeeTest, Squish… are their own recording tools. But this strategy presents manifest problems, basically:

  • Maintenance: When we have a great quantity of recorded actions they must be reviewed one by one when changes in the application are common.
  • Unproductive recording: In some situations controls are recorded one by one providing a great quantity of recorded actions. For example, if you want to get the information of a menu (for example, the menu file in an application) the most easily solution is to record all items one by one spending a great quantity of time. See the post
  • Unproductive strategy: Usually in our daily work we focus our attention only in the part of the functionality under test without any global vision.

To surpass these problems it is recommended a strategy based on change the way of thinking for understand the software that you are testing from a general vision. The strategy has a general purpose and can be used for all specialized software.  It is based on the next points:

  • Improve the maintenance: Get the information from the parent and from it obtain all the children’s. With this way of working you only need to capture the UI control of the parent of the menu and from it to get all the items of the menu reducing the spending time (in reference to recording action method) and increasing the maintenance.
  • Avoid recording actions: Store the information related with controls instead of record it. See post How to get UI Controls with Coded UI Test Builder without recording actions
  • Smart strategy: First analyze how many controls types have the UI and next start working.

Also, to support the strategy proposed it is suggested to provide a layer structure since this way of working provides the next advantages:

  • The division of the solution into separate layers improves the maintenance.
  • Changes in one part of the solution should impact in other parts minimally.
  • Certain components must be reusable in different modules.

Therefore, the most basic structure can be schematized as:



The lowest layer of abstraction, it is the basis of the system. It represents a Map of the user interface (UI) ordered in a tree structure. Here, it is to possible visualizing the UI Controls.


This layer presents a set of classes to deal with UI Controls stored in UIMap. Whether with or without recording actions the associated information about controls is stored in the UI Control Map (see post How to get UI Controls with Coded UI Test Builder without recording actions). With the strategy presented here we don’t have created the method that manipulates the action (for example click a menu item) and therefore the creation has to be done a posteriori (see post

For example in the particular case of .net in Visual Studio, the layer structure can be:



It is the most external layer where are implemented the test cases using methods created basically in the FunctionalActions layer.


Here, different classes that can be used transversally in all layers are created. Here, it is recommended to create a class to store the constants that can be used as key in dictionaries, classes to access to XML files, etc….

This post is only an approach to review a strategy  that is well known in automated testing from a general point of view, independent of the technology used. To complete the explanation other posts have been provided and will be provided in the future.


How to get UI Controls with Coded UI Test Builder without recording actions

Author: Alfonso Alarcón

One of the most powerful technologies to work with automated testing is the Coded UI Test Builder included in the Enterprise version of Visual Studio 2015 (previously Premium and Ultimate Visual Studio versions) [1, 2]. It presents the well know recording tool to get automated testing but other procedure can be follow to save efforts and improve the maintenance in large automated testing projects. It follows the Add a new control to the UIMap tool. In the next a set of points to get UI Controls with this tool are presented:

  1. The first step is to create a Coded UI Test solution in Visual Studio
  2. In the created solution go to uitest (right button) and Edit With Coded UI Test Builder


  1. Here, it is show the two principal tools to work with Visual Studio in automated testing:
    1. Recording tool marked with A in the next screenshot.
    2. Add a new control to the UIMap tool marked in B in the next screenshot. As commented, the strategy presented here is based on get UI Controls with this second. To work with it you must apply it on the desired control in the UI of the application or web.


  1. Next add the captured data to the UI Control Map by means of To Add a new control to the UI Map marked with C in the next screenshot. Use the option copy to clipboard (D in the screenshot) to get the text of the UI Control and apply it in the code later.


  1. In UIMAP.uitest go to UI Control Map where the details of the UI control are shown.


A last comment, the name of the stored UI Control can be changed. As the number of stored UI Controls is increased the difficulties to understand the meaning  of them increases. Therefore it is a best practice to rename UI Controls in function of its content.




Why automated testing?

Author: Alfonso Alarcón

Automated testing is a process to test the functionalities of a software (application, web, mobile,…) taking the role of an end-user to identify any unexpected behavior or bug.  In this way of working the tester writes scripts and uses specialized software such as Visual Studio, HP UFT, Ranorex Studio, SeeTest, Squish or Selenium among others. It is used to re-run test scenarios that were performed manually, more quickly and repeatedly. Automated testing should be used by considering the following aspects:

  • Large and critical projects
  • Projects that require testing the same areas frequently
  • Requirements that do not change frequently
  • Availability of time

Automated testing provides the next benefits:

  • Best Efficiency
  • Reduce task cost
  • Consistency of test execution
  • Reducing cycle time of regression test cycles
  • Repeatability
  • Coverage
  • Reliability
  • Reusability of test products
  • The created scripts can be launched outside office hours extending the time dedicated to test

It is important to mention that is not possible to automate everything in software, web or mobile, and this is a recurrent misunderstanding. There are areas that could not be automated such as those where are required the manual operation in some part of testing. Of course, in some cases, it is possible semi-automate a part of the software coupling manual and automated testing. Besides, it is not recommendable to provide automated testing in areas where the time of implementation is too large making on this manner the automation not viable.