Software QA FYI - SQAFYI

How to Pick Testing Tools

By: Rex Black

Many of us got into technology because we were fascinated by the prospect of using computers to build better ways to get work done. (That and the almost magical way we could command a complex machine to do something simply through the force of words coming off our fingers, into a keyboard, and onto a screen.) Ultimately, those of us who consider ourselves software engineers, like all engineers, are in the business of building useful things.

Of course, engineers need tools. Civil engineers have dump trucks, trenching machines, and graders. Mechanical engineers have CAD/CAM software. And we have integrated development environments (IDEs), configuration management tools, automated unit testing and functional regression testing tools, and more. Many great testing tools are available, and some of them are even free. But just because you can get a tool, doesn¡¦t mean that you need the tool.

When you get beyond the geek-factor on some tool, you come to the practical questions: What is the business case for using a tool? There are so many options, but how to I pick one? How should I introduce and deploy the tool? How can I measure the return on investment for the tool? This article will help you uncover answers to these questions as you contemplate tools.

Let¡¦s start with the business case. Remember: without a business case, it¡¦s not a tool, it¡¦s a toy. Often, the business case comes down to one or more of the following:
„h There¡¦s no way to perform some activity without a tool, or, if it is done without a tool, it won¡¦t be done very well. If the benefits and opportunities of performing that activity exceed the costs and the risks associated with the tool, there¡¦s a business case.
„h The tool will allow you to substantially accelerate some activity you need to perform as part of some project or operation. If that activity is on the critical path for completion of that project or operation, and the benefits and opportunities of accelerating the completion of that project or operation exceed the costs and the risks associated with the tool, there¡¦s a business case.
„h The tool will allow you to reduce the manual effort associated with carrying out some activity. If the benefits and opportunities from reducing the effort (over some period of time) exceed the costs and the risks associated with the tool (including the effort associated with acquiring, implementing, and maintaining the tool and its various enabling components), there¡¦s a business case. There can be other business cases, but one or more of these will frequently apply. Sometimes the business case masquerades as something else, such as improving consistency of tasks or reducing repetitive work, but notice that these two are actually the first and last bullet items above, respectively, if you consider them carefully.

Once you’ve established a business case, you can select a tool. With the internet, it is easy to find candidate tools. Before you start that, consider the fact that you are going to live with the tool you select for a long time—if it works—and potentially spend a lot of money on it. So, I recommend that you consider tool selection as a special project, and manage it that way. Form a team to carry out a tool selection. Identify requirements, constraints, and limitations. At this point, start searching the Internet to prepare an inventory of suitable tools. If you can’t find any, then perhaps you can find some open source or freeware constituent pieces that could be used to build the tool you need? Assuming you do find some candidate tools, you should perform an evaluation and, ideally, have a proof-of-concept with your actual business problem. (Remember, the vendor’s demo will always work, but you don’t learn much from a demo about how the tool will solve your problems.) With that information in hand, you’re ready to choose a tool.

Full article...

Other Resource

... to read more articles, visit

How to Pick Testing Tools