Dion Johnson use the martial arts metaphor four common issues with automated tests and how test automation specialiasts can "train" their scripts to identify, capture, and handle these problems. In this week's column, Dion talks about how to make develop test automation scripts that are flexible and reusable.
The martial arts are composed of various methods of combat that serve the purpose of defeating an opponent or defending oneself from a threat. Automated test scripts have an opponent, and that opponent is the application that the scripts are created to test. This opponent tries to prevent the automated scripts from winning the match by stopping the successful execution and detection of existing errors in the application. As test automators, it is our job to train those scripts for dynamic, hand-to-hand combat with the application.
Often test automators push automated test scripts into combat with the assumption that the application is simply going to let the script win. We assume that data never gets corrupted, scripts never need to be maintained, unexpected events never happen, and each test objective has only a single path. For this reason, scripts often fail easily, require excessive maintenance, and repeatedly overlook simple defects.
Application behavior is dynamic, so it's time that we train our automated scripts to be more dynamic via the techniques provided in the automation martial arts known simply as "Taekwondo-mation"! Taekwondo-mation comprises relatively simple techniques that can be employed without the implementation of an overly complex framework.
Taekwondo-mation, like many of the martial arts, places a focus on four key principles:
- Flexibility-Dynamically inputting data
- Balance-Inputting dynamic data
- Self-defense-Exception handling
- Strikes-Dynamic path handling
I will discuss each of these principles in future articles, but this article focuses on the principle of flexibility.
In Taekwondo-mation, flexibility addresses the ability to stretch a minimal amount of scripting as far as it will go. Dynamically inputting data, which simply refers to the ability to input or verify a lot of data with minimal scripting, greatly increases the elasticity of the scripts. Elasticity is important because time and resources often are limited for automated script development. Reducing time and effort involved in the script development and maintenance helps to make more scripting and analysis possible, which ultimately will help to increase the coverage achieved by the scripts.
This principle is similar to a data-driven automation approach. Data-driven testing addresses the ability to input multiple values into a field by parameterizing the field's inputs. The approach being introduced now actually suggests parameterizing the fields themselves, as well as the inputs. This level of parameterization provides the ability to input a variable number of data elements with a single statement.
The flexibility principle should not be confused with keyword automation framework. Keyword automation still typically requires each and every input to have a separate line in the keyword file. The technique being proposed here can be used to reduce the amount of statements necessary for automating a test, whether using standard scripting or keyword automation.
Let's examine the typical data-driven approach to inputting data. The data may be maintained in an external file, as in table 1.
Table 1: Data Table
The information then may be entered into the application with statements that resemble those in figure 1.
Figure 1: Standard Input Code Structure
Using a data-driven approach allows all three rows of data to be entered using the same group of inputs, but each input into a specific object still requires a separate statement (illustrated in the highlighted statements in figure 1). This can be particularly arduous when there are a lot of fields that require input on a given page. Not to mention that if it becomes necessary to come back to the page and verify the data still exists in these fields, another set of statements must be added to the test to verify each field. Not only is this laborious, but also it