Object orientation, the least talked about component of test automation, might be the most important factor. In this column, Dion Johnson explains how effective test automation is heavily reliant on objects.
There are times when my right brain activity really increases, which leads me to an extremely poetic state of mind. For this reason, I'd like to begin this column with a poem that I wrote about test automation called "The Object of My Desire":
Roses are red,
Violets are blue,
The whole world thrives on objects,
And automation does too.
While I know that you readers are probably at your computers giving this artistic mastery of the written language a spontaneous standing ovation, I must request that you compose yourselves, so that I may draw your attention to the subtle—or maybe not so subtle—message within. That message is that effective software test automation implementation is reliant on—even married to—concepts surrounding software objects. This is a little-explored but important fact, because a firm understanding and utilization of object-oriented concepts is a key ingredient for software test organizations that desire to implement an effective test automation effort. In this column I identify common object-oriented concepts and then explore various ways in which these concepts lead to desired levels of test automation.
Object-oriented programming is a type of programming in which programmers can define modular components called classes (objects) that allow for the efficient creation of software. These objects may then be arranged into a hierarchy known as an object model. When talking about object-oriented concepts we must understand the basics of classes and object models, so let's begin there.
A class is a template for multiple objects with different features, and each class may have properties, operations (methods that can be applied to the object), events, and collections. Properties are simply object variables that may be maintained throughout the life of the object, while methods are repeatable actions that may be called by a script that references the object. Events are also repeatable actions, but these actions, unlike methods, are not explicitly called by a script; they are automatically executed based on an action performed by a user (e.g., mouse click, scroll, etc.) A collection is a set of data or objects that are of the same type.
To help further explain these concepts, let's examine the class illustrated in figure 1.
|Figure 1: Class/object illustration|
The class in the figure is a Button class, and it has two properties that define the features of all buttons created from this class: shape and text. There are two objects (instances of the class) illustrated in the figure, and both have shape and text properties, but the values for shape and text are different for each button object. The first button is rectangular in shape, and has the "R Button" text on it, while the second button is oval in shape, and has the "O Button" text on it. Each button also has a method that can be performed on it—the click method, which means that you can click the button. The two button objects collectively make up what is called the Buttons collection. This collection provides the capability of referring to each button based on its position in the group.
Therefore, object 1 can be referred to in two ways:
- By its collection location (i.e., Buttons Collection object 1)
- By its properties (i.e., the button that has a rectangular shape and reads "R Button")
Many, if not most of today's software applications are built using object-oriented concepts, and the objects that compose the application (e.g., windows, buttons, images, links, textboxes, etc.) are arranged into a hierarchy known as an object model.
The Marriage to Automation
With this information in place, the question becomes "How do these object-oriented concepts support my desires for software test automation?" The answer to this question is manyfold.
Answer Part 1: Objects and object models make modern functional automation possible. Once upon a time, function software test automation primarily used an "analog" approach that relied on specific coordinate locations of a screen or application window for performing mouse and keyboard operations that simulated user activities on the application. This was slightly unreliable and difficult to maintain on a large scale, because when the screen, window, or application components moved ever so slightly, the automated test would fail because it was trying to operate on an element in a position in which it no longer existed. Modern test automation conversely takes an approach that locates the objects on the screen based on properties that define that object and then performs the desired operations once the object is found.
Answer Part 2: Object-oriented concepts provide the ability for more effective use of automated test tools. While the modern object-oriented approach to test automation helps increase the reliability and robustness of automated tests, it also increases the responsibility of the software test automator. Since most application objects have multiple properties that can be used to identify uniquely an object on the screen, it often becomes the responsibility of the automator to determine which properties to use for this purpose. For example, in figure 1 I could use the Shape property, the Text property, or both for referencing the desired button on the screen. Most commercial automated test tools have a feature known as an object map (aka "GUI map") for the purpose of sustaining and configuring this information in a single, more easily maintainable way.
Since object properties are normally transparent to the application users, changes to these properties are often done under the radar. Since automated tests rely on these properties to identify objects on which operations are to be performed, such changes can cause scripts to "break" or fail. When this occurs, it is then the responsibility of the automator to be knowledgeable enough in object-oriented concepts to assess the situation, determine whether or not the failure can be fixed by adjusting the properties in the object map, and then making the appropriate adjustments. It is also the responsibility of the automator to be knowledgeable and pro-active enough to configure the object map to use the minimum number of properties for uniquely identifying objects in the application, and to select properties that are less likely to change on a regular basis. There may also be a need for automators in some situations to confer with developers in an effort to get them to develop the object with specific types of properties that make automated testing easier.
In addition to opening up automation to the use of object maps, object-oriented concepts also provide other ways of increasing the effectiveness of automated test tools—ways that include enhanced verification points, exception-handling, and the ability to externally control the automation tool itself from batch scripts or the command line.
Answer Part 3: Object-oriented concepts provide the ability for more advanced automation. Object-oriented concepts definitely make it easier to develop and implement more advanced automation frameworks, such as the Model-Based and Keyword frameworks. These frameworks build modular, often application-independent components that allow specific automated tests to be built using more user-friendly approaches involving text files and spreadsheets. In addition, the concepts open up a world of process automation capabilities. Process automation is a term being used to define the automation of simple, yet tedious and time-consuming processes that are conducted on your software projects. These processes might include data extraction and manipulation, file manipulation, report generation, etc.
Since many applications are built with objects and make their object models accessible for scripting, many processes can now be automated very easily with a commercial tool or even a simple scripting language. By accessing an application's object model, a script is able to control and manipulate elements of a production application, file system, or local program (e.g., word processing program, email programs, etc.) and its elements.
When test automation is discussed, you normally hear about functions, verification points, and data-driven approaches, while object-oriented concepts often go unmentioned. These concepts are at the heart of effective test automation, and it is therefore the lack of understanding of these concepts that's at the heart of many automation failures. Object models, objects, object properties, collections, and methods must be studied and well understood in order to achieve one of software testing's ultimate desires—to produce effective, efficient automation that helps to attain overarching quality goals set by our projects.