Automation standards groups, in the testing industry and beyond, pop up all the time. In each case there is a group of founding members that have a mission to make life easier for users of their products or solutions. It was no different when we came together to form NTAF in 2010. But NTAF is radically different from other groups, and the evidence was laid out for all to see during our first “plugfest.” My name is Kris Raney and I am the director of software development at BreakingPoint Systems, a founding member of NTAF. Today we are going to look at how far NTAF has already come in developing and promoting interoperability standards for the network test automation industry.
Proving Interoperability Throughout the Process
There are four key aspects of the NTAF effort that I think will make it a huge win, and they show why BreakingPoint works closely with the group:
- It moves the point of automation from a programming API to a network-based API.
- It makes use of the existing XMPP protocol, with XML-based messages.
- It requires the interfaces provided by tools to be self-describing.
- It’s being developed using a “show me how it works” approach, not a theoretical debate.
This last point is a defining difference for NTAF and why we don’t simply meet about these things and debate implementations. Instead, NTAF takes a proactive approach and puts these things consistently to the test.
Just a few months ago several of the NTAF members (BreakingPoint, Fanfare, Ixia, Spirent, and Verizon) put our initial draft specifications to the test. During the beginning of the week, each company chose the implementation language that made sense for them, and there were several—including TCL, Java, python, and an implementation that would work for any Windows CLR language. Then test tools that were located in two separate cities in California, two separate cities in Texas, and a server in the cloud started to interact. All of them were communicating through a variety of corporate firewalls, VPNs, and network security.
By the end of the very first day, these tools were functionally talking together, and by the time the demo came on Friday, they were working quite well together. The demonstration clearly showed multiple different combinations of cross-vendor interaction. Performing this live implementation of the specification not only showed us we were on the right track, but, more important, it also identified areas that needed improvement—and that’s the great thing about having made real implementations. The NTAF 1.0 specification isn’t being made in a theoretical vacuum, and these things will be fixed.
Very soon we will officially publish the NTAF 1.0 specification. Iterations of this specification have already been put to the test, as I mentioned, to show how NTAF is moving the test automation industry forward. And with the introduction of 1.0 we will continue to put our work to the test and proactively work together to produce a specification that is strong in its vision and in its capabilities.
