Metaphorical Description of Automated Testing

In the forest of software testing strategies there is a weeping willow known as functional automated testing and an oak known as performance testing. These relatively minor players in the woods provide support to the greater surrounding edifices and ensure their majesty against slight.

The willow has a great reach. With a feather-like touch the willow gently encourages the furtherance of the development of the citizens it touches. Its outstretched drooping branches touch a great many of the other forest denizens. A wispy encouragement to move into unchartered areas with the secure knowledge of the willow being near and ready to provide any support.

The majestic oak is a stalwart solitary figure. It provides a backbone of strength upon which the forest population can depend and use as a central core around which to develop and grow. From its strength comes the certitude for the future as well as the assurance that the present is adequately covered.

A typical forest is not solely composed of trees and this one is much the same. The mistletoe can be considered to be a parasitic lecherous growth sapping the very life from the tree on which it grows. In this case, however, it is not the essential essence of the woody-citizen that is being drained, but those things which imperil its beauty. As such the mistletoe test enablement tool magically transforms its victim into an ideal focused specimen with little superfluous baggage weighing down the lofty elegant idealisms to which it was born.

Willows, oaks and mistletoe cannot grow without a suitable environment. Knowing how, where, when and which to plant is of primal importance to a successful forest. This is the realm of the horticulturist – a specialist within the greater forest of software testing.

Data Driven Frameworks

The notion of a data driven automation tests is in itself a notion of grandeur. It is a highly commendable practice however what makes an actual data driven script?

The basic notion of a data driven script is one in which the data has been separated from the code. In its simplest form, a data driven script can be considered to be a simple case of centralizing the data in variables. The variables can occur in a group within the script and can be modified at need and in a central location.

The above notion is much the same as a tool vendor's concept of a data driven script. How much extra benefit is achieved by simply moving the data variables to an external file? Simpler interface. Maybe. Sure. Huge numbers of data variances for the same script. Not entirely. An array would provide the same features and would probably reduce execution time as well. Essentially the point of using an external data file is thus the simple interface that the file tool might provide.

Lets preclude my disillusionment and implement a data driven script in the above manner. It works wonderfully. Along comes an interface change. The changes require that 3 fields be added, 2 edits change to lists and 1 field is removed. Lets look at what the changes entail:

1. The data file is updated to include the new fields and remove the old fields. The new list entries are also updated to ensure that the correct items are selected
2. The GUI/object reference map is updated with the new objects and to update the edits to lists
3. The script code is updated to point to the additional fields. The function calls for the edits are changed to function calls for lists. The code for the removed field is commented out or deleted

But wait a bit. This is a data driven script. Why does the script code have to be updated? Surely a data-driven script precludes the necessity of having to modify code. I'd expect that to be the point of the exercise. So we'll call an implementation above, a pseudo data driven framework as it provides the illusion that the script is data driven.

So what makes a true data driven script. Quite simply a means of mapping the data parameters to the object references. The map will provide a means of identifying an object and its data value by a common reference. By following a simple object naming rule, its simple to identify the type of object being dealt with (for example, using "ed" in front of edit fields, "ls" in front of list fields). Using an object naming rule has drawbacks in terms of having to maintain the names. However, the automation tool may well provide a means of identifying the type of object through its internal mechanisms. If such is the case, then the naming scheme can focus on what it should focus on and that's the object's user name/purpose.

Having the object type means that the function needed for that object is immediately known. A function developed to take the type of object and perform the appropriate action simplifies the scripting. By parsing through the parameter list of a data file with an object to action function its possible to create a script as being purely data driven. In this environment the following changes would be required (using the same example)

1. The data file is updated to include the new fields and remove
   the old fields. The new list entries are also updated to ensure that
   the correct items are selected
2. The GUI/object reference map is updated with the new objects and to update the edits to lists

So it should be possible to only have to maintain data. Maintaining data is a lot less effort and less riskier than scripts.