Michael,
>> "Imagine trying to create an
automated spelling and grammar checker without really *learning*
English."
>Actually, No...
that is a programmers job... I am not making the spelling checker... I am
checking that the spell checker catches all the mis-spellings on the page...
> ... I really don't concern
myself with how it works... only THAT the spell
checker works...
Actually, no. I
mentioned that the metaphor was a stretch. My point is this: test
automation is an oracle--that is, a principle or mechanism by which we recognize
a problem. The less you know about your oracle, about your principle or
mechanism, the greater the chance that you will miss something important.
If you didn't know, for example, that the spelling checker works merely by
comparing each word in your document to a list of existing words, you might
ascribe more intelligence to the spelling checker than you ought, and sir ten
words wood get miss spelled, and ewe wood knot no a thing about
it.
> In a similar vein... I am
looking to create testing tools that checks a feature on a page... click here...
look for text there... fill in that box... move this widget to an x/y spot on
the page... etc...
How do you expect to do this
/reliably/ if you don't know how to instruct the machine to do it? You can
cut and paste all you like, but the more you do so, the more you abdicate the
testing task--the performance and intelligent evaluation of the test--to the
machine. In my view, that's exactly the problem with the way many testers
do automation; they let the machine do the thinking for them. Bear in mind
that I'm a noted automation skeptic for precisely this reason. If we're
going to deploy automation, we should do it wisely and
well.
> Like
my Honda Element -- an internal combustion engine -- I use in the morning
to get to work... I really don't want to worry too much about HOW it
functions ... just THAT it functions...
I remember my mom
using that metaphor with respect to her computer. A few years later, she
started selling software. My response (which was apparently
effective) was that she didn't need to learn how the engine functioned, but
she did need to be comfortable with the controls on the dashboard, finding the
gas tank, checking the oil, and making sure the wiper fluid was topped up.
She needed to know how to control the car, not count on it to drive her to
work.
I'll own that we're
talking about a bit more of a commitment here than you might want to make.
My concern would be that if you don't know a sufficient amount about HOW it
functions, you won't know THAT it's functioning in a way that /doesn't/ meet
your needs, or that misleads you into thinking that you're doing better testing
than you are. My father-in-law afforded a great example of this
recently. He was using my power drill, and he had misplaced the bit
such that the bit wasn't perpendicular to the chuck, and the clutch on the drill
was making a terrible noise. Since he wasn't familiar with the proper
operation of the drill, the damage that he was doing to the drill, the bit, the
screw, the wall, and so on. This wasn't a matter of him knowing about the
internals; it was a matter of knowing how to use the
tool.
WATIR is like a
debugger, in that debuggers neither find nor fix your bugs; YOU do that.
Rest
assured, though, that learning Ruby is one of the more pleasant experiences
you'll have learning a programming language. And you might want to review
the list of helpful things that I posted in the original
message.
---Michael
B.
_______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
