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 https://automatedtestingtools.wordpress.com/2016/04/17/how-to-get-menu-elements-from-the-parent-element
- 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 https://automatedtestingtools.wordpress.com/2016/04/15/how-to-get-menu-elements-from-the-parent-element).
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.