For most of the test tools available today, you have to write test scripts in the tool's scripting language. What drives me crazy is that most vendors have their own special language that you must learn in order to use their tool. They often have recorders to help you generate code, but invariably you need to go in and make changes and write code yourself. And you end up having to learn another language, another vendorscript, another dialect that is good for nothing but the one tool.

Undermining Collaboration
Because a vendorscript is a specialized language, developers are less likely to know it and little inclined to learn it. I frequently counsel testers and developers to work together on test automation projects. There are many reasons why this is a productive collaboration, but vendorscripts get in the way. They split testers from developers and from each other into tool-specific language isolation. This reduces the opportunities to share, collaborate, and improve the craft.

We have enough trouble bringing developers and testers together in the testing process. The last thing we need is an inherent obstacle from the get-go in our testing tools. Ask a developer to learn Visual Basic? No problem. They can always use that knowledge in the future. Ask a developer to learn a specialized language unique to one tool? You're dreaming. You may already be having trouble getting the developer to pay attention to testing, and now you're asking for more. Why spend money on a tool that's going to undermine the collaboration efforts between testers and developers?

Dialect Stew
There are various dialects of vendorscript. Some use C-like languages. What does this mean? It means that the code looks like C, but it doesn't have pointers, so you can't use any of the complex data structures that you learn about in any C course or book. C is really a poor basis for a scripting language. It is compiled, while test scripting languages are interpreted. This is why the C-like languages can't support pointers.

Others use a Visual Basic-like dialect. If you know Visual Basic, the code will look familiar, but you won't be able to make use of standard Visual Basic libraries. Moreover, the things you learn about Visual Basic may or may not apply to the vendorscript.

Still another tool uses an object-oriented mongrel vendorscript. Being object-oriented is nice until you learn that modifications to a class won't be inherited to its subclasses. What? This vendorscript thinks that this is a better arrangement for testing. Whether this actually helps testers is debatable, but what testers really need is not a special language designed for testing. Rather they deserve and work better with a full-fledged language.

Some of the newer test tools are using real scripting languages, such as JavaScript or Visual Basic for Applications. I can only hope that this tend continues. Moreover, it would be nice if some of the older tools would be reworked to support standard languages. Standardized languages have formal specifications, which tend to favor ease of programming instead of ease of implementing the interpreters. This makes them easier for you and your test team to use.Reinventing the Wheel
The drawbacks of vendorscripts were illustrated in a recent article that described how a couple of test automators had collaborated to add stacks and queues to a vendorscript. The point of the article was to demonstrate what test automators could do when they worked together, but the lesson I drew was that vendorscripts can lead test automators to waste a lot of time and effort reinventing wheels. Stacks and queues are elementary data structures that require little effort to implement in standardized languages. I can sympathize, because I've been in the same situation. I have had to build libraries to support string manipulations, date math, and calculating permutations for various vendorscripts. Some vendorscripts have libraries for such things, but the libraries for standardized languages are much larger and more robust.

Back in the Old Days
Lots of nontesting tools have embedded vendorscripts as well. And it used to be even worse. About a decade ago, John Ousterhout decided to do something about it. He designed Tool Control Language (TCL), made it easy to integrate with C, and released it into the public domain. TCL is now used in some public-domain test tools. Ousterhout makes a distinction between system programming languages (such as Pascal, C, C++, and Java) vs. scripting languages (such as Perl, Python, Rexx, TCL, Visual Basic, and Unix shells). System programming languages are better for building from scratch and optimizing for performance. Scripting languages are better for rapid development and reusing code. They are great for test automation. Some of the test tool vendorscripts pre-date Ousterhout's advances—created before TCL and when Perl was still in its infancy. But that was then. There are plenty of options now.

Retiring Vendorscripts
So with plenty of options, vendorscript should be retired. With one exception, there are no third-party books that you can use. You'll have to rely on books from the vendors, which may or may not be frank about the vendorscript's shortcomings. Courses are also hard to come by, expensive, and may require travel. If you are hiring, it will be hard to find people who are already trained. Test automation is hard enough without us having to flesh out the vendorscripts that come with many tools. Developers wouldn't stand for programming languages with such limitations. We shouldn't either.