Most test tools come bundled with vendor-specific scripting languages that I call vendorscripts. They are hard to learn, weakly implemented, and most important, they discourage collaboration between testers and developers. Testers deserve full-featured, standardized languages for their test development. Here's why.
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.
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?
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.
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