Automated Testing Tools - Software Testing: Testing Across the Entire Software Development Life Cycle - page 161

by only a dozen tool vendors who could provide these tool suites. With sophisti-
cated tool suites available, the user demand for more powerful, easier to use, fully
integrated tools was replaced by a user demand from a surprising new direction.
As with all software product designs, each tool suite had limitations. Some of these
limitations were apparent during tool feature shopping. Other limitations surfaced
with hands-on tool experience. As companies began to have second thoughts about
the tool suites they purchased and started shopping for new tool suites, they discov-
ered that they could not easily leverage their sizeable investment in the current tool's
training, scripting, data, results, and reporting when migrating to a different vendor's
tool suite.
This tool suite migration roadblock presented the tool vendors with an interest-
ing dilemma: eliminate the migration roadblock and customers can abandon a prod-
uct too easily; provide no migration assistance to other tool suites and risk losing
initial sales due to customer-perceived “bundled” products that were so despised in
the 1960s and 1970s. Some amount of migration assistance is the desirable compro-
mise, but how much is “some?”
In the middle of the 2002-2003 timeframe, major tool suite vendors chose a
professionally creative and potentially durable long-term solution to the migration
challenge. By the time this textbook is published, their solution will be either ac-
cepted by the tool customer community as the norm or rejected by the tool customer
community causing vendors to seek a different solution. The chosen solution is for
all test tool vendors to adopt a standard product architecture using standard archi-
tecture components. The standard architecture and components afford a moderately
diffi cult but achievable suite-to-suite migration while allowing each vendor to retain
the majority of its unique capabilities.
The new architecture and component standard chosen by the automation tool
industry is Eclipse/Hyades.[43, 44] The Eclipse Foundation describes itself as an
independent, open ecosystem around royalty-free technology and a universal plat-
form for tools integration. Eclipse is a nonprofi t corporation that was established in
November 2001 and is comprised of many of the computer industry leaders. The
Eclipse web site documents the current corporate membership.
As described on the Eclipse web site, the Eclipse Platform is an integrated
development environment that can be used to create a diverse collection of ap-
plications based on Java and C

. Eclipse provides a plug-in-based framework
that makes it easier to create, integrate, and utilize software tools, saving time and
money.
Hyades is the name of an Eclipse project to provide an open-source platform
for automated software quality tools. Hyades delivers an extensible infrastructure
for automated testing, tracing, profi ling, monitoring, and asset management. Finally,
Hyades is designed to support a full range of testing methodologies via an open-
source infrastructure layer and Eclipse plug-ins.
Concluding the tool background discussion, it can be seen that a corporate soft-
ware tester will normally encounter, use, and become profi cient in maybe a dozen
different tool suites. This number is impressive but it is nothing approaching the 300
individual tools in the market.