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? Danny and Alan have encountered this frustration many times before, and in this week's column, they'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.
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:
- 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,
- 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
- 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:
- Select "Run" from the Start menu
- Enter "cmd" to open a DOS shell (or "command" on older versions of Windows).
Consult a DOS reference and learn commands such as:
- "fc /b" to compare two files to see if they match
- "type" and "more" commands to see the contents of a text file, or
- 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.
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