TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Being Resourceful When Your Hands Are Tied



A StickyMinds.com Original
Article Picture
Being Resourceful When Your Hands Are Tied

By Danny R. Faught/Alan Richardson

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: 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.


Rally Software
StarWest Speaker Better Software Conference and EXPO 
 
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" 
 
Danny R. Faught, "Software I Don't Install" 
 
Recommended Resources 
DOS Reference available at http://www.computerhope.com/msdos.htm
 
For a test utility implemented in VBA visithttp://www.compendiumdev.co.uk/excel/
 
VNC available at http://www.realvnc.com/  
 
A public Unix Server is available at http://sdf.lonestar.org/
 
Two commercial tools that run virtual machines are VMware and Virtual PC. 
 
James Bach's PerlClip tool, available at http://blackbox.cs.fit.edu/blog/james/archives/000170.html, is an example of a Perl script packaged as an executable Windows file. 
 
Examples of useful Web-based applets are: 
VGJ 
and  
yED


About the Author

Alan Richardson is an independent software testing consultant based in the UK. Alan spends a lot of time exploring different ways to approach, and think about, his software testing activities. Explore what he's learned by reading his essays posted on his web site at www.compendiumdev.co.uk.

Danny R. Faught is a U.S.-based testing consultant, author, and trainer. Danny is the publisher of Open Testware Reviews. Visit www.tejasconsulting.com for more information.



Back to Top
 
 

Member Comments
Add Your Comment
 
Comment:    
by Derek Johnson 6/28/2005

How about this? Run a Web Server without installing any software. Copy RitLabs Tiny Web server to a shared drive accessible from the target system. Locally start the server on the target system; result: web server capable of executing CGI scripts with not a single file copied to the target. Very useful when the target system is locked down in various ways.

 
 
Comment:    
by neill mccarthy 9/10/2004

A good article. I have a recently added a portable USB hard drive to my toolkit with a number of the tools I use installed on there to work on any PC, most places with a lock down policy still seemed to have left the USB ports open and many have nothing in the security policy about its use just the taking of data from site without permission. The other recent discovery of mine has been the CD based distro's of linux that run of the disk not the hard drive. I am still playing with these but see the day soon when I will always be carrying my mandrake move to site.

 
 
Comment:    
by Prakash Marar 9/1/2004

Great stuff. Danny should have added more on this, since he is an integral part of Open source based testing solutions. Several open source testing framework and utilities would very much help on a low cost "open automation". I was doing some research on Opensource based testing tools and framework few months back and the result I got was amazing. There are many open source tool and framework, can be brought together to make a very good testing platform, that can't be done by any commercial tools.

Author's Response:
9/2/2004    
The open source world certainly has a lot to offer. I monitor sourceforge.net on a daily basis to see if there are any tools, that aren't classed as test tools, which might help in my testing. - Alan

Another way your hands can be tied is when you don't have a sufficient budget to purchase tools, or when you do have a budget but acquiring the licenses takes weeks. Open Source and freeware can open doors for you in very short order. See my web site (linked above) for articles with more information about open source tools. Also, see my talks at the upcoming Better Software and STAR West conferences. -Danny


 
 
Comment:    
by Richard Wagner 9/1/2004

Very informative. I guess we are lucky to have the luxury of a separate automation lab where we control the environment. We have our own internal LAN for our test machines which connects to the test manager server which in turn is on the company LAN. This upsets the Server Nazis" to no end as they can not see our test boxes and therefore can not push down those constant updates to security. It never ceases to amaze me how a whole generation out there have not experienced the DOS era! I feel "OLD"! Keep up the good work Danny and Alan. Rich Wagner

Author's Response:
9/1/2004    
One thing you have to be prepared for is that your non-IT maintained test systems might not be allowed on the corporate network at all. Regarding your DOS comment - it really does seem like a lost art! -Danny

 
 
Comment:    
by Issi Hazan 9/1/2004

Ruby - My ultimate language for commandline automation. It's free, Linux and Windows compatible(Now without need to install bash emulator) , Very fast to learn and has object oriented.

Author's Response:
9/1/2004    
You won't need bash if you're running Ruby, but you will need the Ruby interpreter (same as for any scripting language). I do usually prefer a full-featured scripting language over shell scripts, but when it's not possible to install the script interpreter or to turn my script into an executable, I'll resort to writing a shell script or batch file. -Danny

 
 
Comment:    
by Bernard Homes 8/30/2004

Two of my favourite consultants together for one information packed article. What can one ask for except for ? ... except : more of the same. One type of resource I use when I need to automate tests for legacy applications (ie for terminals with 80 char X 24 lines displays such as 3270, 5250 or VT220) is a simple terminal emulator. This enables the use of commercial test automation tools (with a little programming). Thank you both for a nice article. Bernard Homes

Author's Response:
8/30/2004    
Thanks Bernard. A well featured terminal emulator really helps the testing process for VT applications. In addition to working with commercial automation tools they often have a macro record/playback facility which can work really well in a VT environment. One of the most successful uses of automation I've encountered was on a project where automated scripts were written in MS Word documents and Word basic macros (pre-VBA) used DDE to control the terminal emulator's API. -Alan


Since Alan can't add comments himself, note that I'm doing it on his behalf, so my name will appear at the end of each author comment. -Danny


 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Infosys

Rally Software




Agile Development Practices 

STARWEST