You work hard to find tools that can help you. You learn how to use and configure them. Then you find yourself working in an environment where you can't even use them. Have you encountered this frustrating situation?

We've been in this situation many times before, and we're here to say you don't have to abandon all hope. If you're creative, you can still find tools to use--even in the most inhospitable environments.

A few specific limitations that might affect testers include:
 

1. Even if you have no barriers to acquiring the tools you need, it's very difficult to convince the IT group managing your desktop PC or server to let you install the tool. It may take more effort for IT to approve the software than the time the tool would save you--if you could use it,
2. One or more of your testing platforms has to be pristine, with no software installed that isn't absolutely necessary for running the system under test. Other software could mask problems in the software you're testing, or
3. You're testing on several different computers and you can't control what's installed on some or all of them.

We'll discuss some ideas of how you can take advantage of the tools at hand below, even if you can't install the ones you really want.

Dive Below the GUI
Most operating systems have a command-line interface, with old versions of MacOS being the only significant exception. You can be much more effective on any random computer if you learn how to use the command-line interface.

On practically any Windows machine:

1. Select "Run" from the Start menu
2. Enter "cmd" to open a DOS shell (or "command" on older versions of Windows).

Consult a DOS reference and learn commands such as:

1. "fc /b" to compare two files to see if they match
2. "type" and "more" commands to see the contents of a text file, or
3. Automate simple tasks by writing a DOS batch file.

Unix-type operating systems, including MacOS X and Linux, host a variety of built-in shells you can use for command-line access. There are dozens of useful utilities that work similarly across all Unix-like systems, such as "diff" to compare files and "grep" to search files. You can use the shell as a primitive programming language by putting shell commands in a file and executing them.

Script an Existing Application
Your computers may already have applications installed that can be used as a testing tool. For example, Microsoft Office allows you to write programs using VBA (Visual Basic for Applications). Even if you can't always install a general-purpose script language interpreter like Perl, you can often find Microsoft Excel running on the computer.

Alan has written several testing tools in VBA using an Excel spreadsheet as the user interface.

Go Remote
Your test tools don't always have to run directly on the system under test. Maybe you need to use a static analyzer, or just a simple Unix utility. There are many ways to access a remote computer when it has the tools you need.

For a full GUI interface, you can use a program like VNC, a Windows terminal server, or a remote X-Windows connection. Or you can use telnet or SSH to get a remote command-line interface. Once you transfer useful data to the remote machine, you can use whatever tools are available there. For example, using a free shell account on a public Unix server gives you access to the Unix toolbox.

You can also use a flash drive or CD writer for a "sneaker-net" transfer of your data to another computer at your site that has the tools you need, perhaps even someone else's computer.

Go Virtual
A tool that runs a virtual machine can be invaluable. If you can get past the hurdle of installing the virtual machine software, you can install another complete operating system that runs over the operating system already in use. With administrative permissions on this "guest" operating system, you have more freedom to configure it the way you want to.

Buck the System
Some companies never consider setting up a test lab because all of the PCs are carefully controlled by the IT group. The procedures designed to make PCs easy for IT to manage usually hinder using a machine for testing.

Danny recently encountered this situation during a project. He got approval to buy a new PC because the IT group didn't have any spare PCs at the time. This situation gave him the control of the administrator account for the machine, so he could install any tools necessary without IT's approval.

Another way around this issue is to use simple tools that don't require installation. These may be simple executable files you can run from a CD, floppy disk, or USB flash disk. If you want to use a Perl script, you may be able to compile the script into a self-contained executable file and run it on a machine that doesn't have Perl installed.

Two for the Road
Another way to utilize tools remotely is to load them on a web server and access them through a browser. You can write your own tools this way, or use a commercial ASP hosting the tool that also provides a web interface.

Alan likes using Web-based applets for drawing graphs.

If you like to use a third-party screen capture tool, keep in mind that all popular operating systems have built-in screen capture capabilities you can use when you don't have your tool handy.

What do you do to be productive when your hands are tied? We'd like to hear your tips.

Further Reading

• Alan Richardson, "Alternative Testing Tools in Theory"

Recommended Resources

• DOS Reference available at www.computerhope.com/msdos.htm.
• For a test utility implemented in VBA visit www.compendiumdev.co.uk/excel/.
• VNC available at www.realvnc.com/
• A public Unix Server is available at sdf.lonestar.org/.
• Two commercial tools that run virtual machines are VMware and Virtual PC.
• James Bach's PerlClip tool, available at http://www.satisfice.com/tools.shtml, is an example of a Perl script packaged as an executable Windows file.

Examples of useful Web-based applets are: VGJ and yED