|
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 http://sqa.fyicenter.com/art/
| 