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

11.7.2 One-off Testing Setup Costs
We previously stated that the return on investment from testing tools occurs after
three or more repeat uses of the same test scripts. This saving is mostly due to econo-
mies of scale (repetition). The fi rst time a test tool test script is written and validated,
it is an expensive proposition in both time and resources. The only successful argu-
ment for using a testing tool in a one-off situation is that the test results are critical to
the success of the software or that the testing cannot be accomplished manually.
11.7.3 Boundaries of Testing Tool Capabilities
There is a dimension of tool capabilities often missed during tool evaluation and
selection. This dimension is fl exibility with respect to application changes. Some of
the most powerful tool capabilities are viable only if the software does not change
from build to build or release to release. In these cases when the software changes,
many if not all of the test scripts must be recorded again!
Here is an example of both sides of this capability-with-change issue. Classically,
functional test tools for Windows record what is happening on the screen in one of
the two ways. The fi rst way is by the pixel coordinates of the objects of interest (data
fi eld, button, and text message) on the screen. The object coordinates are very precise
and allow some amazing scripting capabilities; however, if the programmer moves a
scripted object one pixel in any direction, the script will no longer execute correctly.
The second way is by standard properties of the objects of interest on the screen.
This method of object recording is independent of the object's screen coordinates.
This means that the programmer can move a scripted object from one side of the
screen to another and the script will execute correctly. This second way of record-
ing objects loses its fl exibility in the long run when the object properties change in
subsequent release modifi cations. In either event, test tool scripts require a level of
ongoing maintenance not usually required by manual test scripts.
11.8 PUTTING AUTOMATED TESTING TOOLS
IN PERSPECTIVE
Anybody who has attempted do-it-yourself projects around home comes to appreci-
ate the value of the right tool for the right job. Similarly, with the plethora of auto-
mated test tools in the marketplace, it becomes important to know the right test tool
for the right test case.
Rather than trying to gain experience in all the available tools, the suggestion is
to understand the touchpoint paradigms of the different groups of tools. As soon as a
tester identifi es the tool paradigm most appropriate for the test situation, the number
of tool choices shrink dramatically. As new tools emerge in the marketplace, testers
can use touchpoint paradigm understanding to place the new tool in a group of com-
parable, familiar tools for further feature comparison.