Hello, this is Todd Law again, vice-president of NTAF and senior product manager at Spirent Communications. Last time I wrote about the various reasons people choose to automate, but this time I wanted to ask an even more fundamental question, namely, what is automation?
This question may seem strange to ask since clearly most of us have some feeling and understanding for what automation is. But if you think about it for more than a few seconds, the answer to the question is not necessarily so clear.
Perhaps let me start by stating what automation is not.
Automation is not the writing scripts or programs. There is a common perception in the networking space where automation is often equated with using the API of a product. Most test tools do indeed provide both a GUI and an API, and both are valid means to using those tools. However, we should not confuse the means for automation with automation itself. It is, in fact, possible to automate using a GUI interface, and also possible to drive many test tools by firing off Tcl commands one by one. With that important distinction being made, I do of course accept that automation is frequently achieved by writing scripts that utilize test tools’ APIs.
So having separated the means by which automation can be achieved from the idea itself, let’s now attempt to state what automation is. If you look it up in a dictionary, you will find a somewhat self-referential definition that says “automation is the act or process of getting a machine to be more automatic”. If you look up “automatic”, you will find something like, “capable of operating without control or intervention”.
If we glue those two definitions together to come up with a single, unified definition (and taking some liberties to simplify things a little) we could then define automation to be “the process of getting a machine to be more capable of operating on its own”.
It is worth noting that the definition uses the word ‘more’ which is a relative term. I like this, because it reflects the reality of automation in that the goalposts keep moving. For example, in the network test space, traffic generators started off as fairly simple frame blasters (which were themselves an extension of even more basic bit blasters). Gradually over time, however, traffic generators have added the capabilities to emulate a plethora of protocols, which are, in a sense, a form of automation, in that packetized responses are sent automatically from the tester to the device under test in response to the stimuli of specific incoming packets. Such emulations hold up one side of a protocol conversation with a counterpart in the device under test. Emulations have been a natural evolution of test tools as the ways in which the Internet is used has exploded over the past decade. Emulations provide the ability to test higher-up layers in the 7-layer OSI model of networking, and the various services that depend on underlying infrastructure.
Supporting multiple emulations is now the norm, and the expectations for automation continue to rise. Routers, and the tools used to test them, now more resemble high-end computers than simple hardware designed primarily for the narrow-purpose of forwarding packets. Routers are now capable of doing so many things that the number of test cases usually reaches into the thousands. Vendors and customers need to apply ever more automation simply to validate the vast scope of functionality, scale and performance, not to mention a continuing cascade of new features with each software release.
So how can network testing be more automatic than it is now?
Well, automation could be applied to many more parts of the network test puzzle: reservation, scheduling, inventory, topology, execution, inventory, reporting and authoring. All of these items are the stated priorities for NTAF. Moreover, since these problems frequently involve the multiple test tools as well as the devices under test, there is a clear need for standards in each of these areas to achieve the efficiencies possible via automation. Creating such standards, and driving their implementation, is the primary objective of NTAF itself. These are the problems we are working on, or will be working on, in the NTAF technical committee.
).