Breaking the Language Barrier

Software testing, especially automated testing, is a nascent profession compared to programming. Because of this, we need to be a little more diligent to reach out to others in the field who have faced—and possibly conquered—the same problems. For example, in my consulting work I've seen automated tool users within the same company, in adjacent cubes, repeatedly solving the same problems—reinventing the same wheels. One automation quandary I faced recently showed me the tremendous value of peering over the cubicle walls and staying in touch with other users of the same tool.

I've been involved in software development and testing for seven years, using automated tools for the last year and a half. Many of the automated tools on the market are sold on the promise of "capture/replay." Capture/replay involves letting the tool record your actions so that they can be played back repeatedly. The customer often expects to open the box, install the software, and have automated tests running the same week. After that, they can sit back and watch.

But this method only really works for the simplest of test environments. To truly reap the benefits of automated tools, a tester needs to code scripts in the tool's language. Although this can be overwhelming to a tester with little or no programming experience, this method gives the tester much finer control over the power of the testing tool, and permits more advanced verification methods and reporting to be used. In my opinion, the greatest benefits of automated tools can only be obtained by resorting to scripting.

Most serious users of automated test tools will invariably come to a point where they need a feature that the vendor’s scripting language does not offer. The more advanced your use of the tool is, the more likely you are to see this. In many cases it is possible to work around the problem using other methods offered by the language. In other cases, it’s worth the effort to implement these features in a custom code library.

Custom Code Libraries
have often found that the most elegant way for me to store data when creating automated tests has been to use a stack or queue. With a queue, the data you store can be fetched in the order in which it was stored. With a stack, the last piece of data you store is the first one fetched. In Figure 1, “hello” and "world" have been stored in a stack. "World" will be the first one retrieved.

Recently I was using Mercury Interactive's WinRunner tool to test a large ERP system for a client. Although useful, the tool utilized a built-in language—TSL—that didn't offer stacks or queues as intrinsic data structures. I was frustrated, because those structures would have permitted me to store data used across different parts of the system in a much more elegant manner.

I unsuccessfully spent some time looking around the Web to see if anyone else had created such an implementation. It seemed like a good opportunity to dust off my data structures book and try to code a stack and queue implementation myself.

This is where it started to get a little interesting.

TSL is a comparatively complete language in that it supports most of the usual looping constructs and conditional statements. It permits users to extend the language by creating user-defined functions. However, the language features usually used to create stacks and queues (pointers, "structs," and dynamic allocation) are missing. It only has strings, numbers, arrays, and associative arrays.

I started to implement my own stack and queue library, but was making slow