RE: article about testers using Ruby.

Brian:

See comments in red...

Thank you for your comments. I will think about them as I write the next
draft. Other comments so far, from both Rubyists and Ruby novices, make me
think I should  leave the level of Ruby detail about the same.

As far as the testing topics go, you'll have helped me be more precise about
my wording. But I don't yield on my claim that the combination of automation
through a scripting interface and manual exploratory testing is a better
default choice than automation with a GUI testing tool. That's not a topic
for this list, though.

My only point is that you cannot use a script interface that is itself
untested to test functionality that that also happens to be accessible
through the GUI. You must test the GUI independently in any case (if only to
prove that it actually accesses that lower-level functionality properly);
whether it's feasible to test every aspect of the GUI with a given automated
test tool in the circumstance that there are custom object headaches to
contend with is not a factor in the need to test the GUI somehow, separately
from the scripting interface. It must be done, manually if necessary. That
was the gist of my concern with your approach. Now having said that I do
think there is value in testing the interface itself through scripting. Just
not as a substitue for GUI testing, however you choose to do it.

In other words, a professional test engineer cannot "shun" the GUI, however
much of a pain in the butt it is to test, with or without an automated test
tool. You *can* however supplement GUI testing with testing of more
programmatically direct means of accessing application functionality, i.e.,
through a script interface (if the application even supports such an
interface).
   This is the first time I've used win32ole and only the second time I've
talked programmatically to Word.

  Do you wan't the truth? It kinda shows... :(


  I'd appreciate suggestions for improvement, keeping in mind that I'm
writing for a novice audience.
4 points:

1. I'm sorry that came out as badly as it did. I apologize for the tone.
2. There weren't any specifics so I could not give any suggestions one way
or the other. There was no code in your snippet that I could comment on, and
your description of OLE as a logical "or" to COM suggested that you yourself
did not understand that OLE is a technology built on top of COM (like other
technologies, such as structured storage, ADO, and so on), not just another
name for it.
3. It may be just a matter of imprecise wording, but given your insistence
that you are speaking to a novice audience, I caution you not to add to any
confusion your audience might be experiencing by attempting to protect them
unduly from the rigors of reading more precise explanations. On my
experience, having gone from "novice" to "experienced" in numerous
technologies, I always appreciate authors who, rather than spare me
difficult explanations or sugar coat them with "kinder, gentler"
ambiguities, engage in them with clarity of thought and a flare for analogy,
metaphor and lots of handy sample code.
4. Word is not a good example for your article. For one thing, it's already
a finished commercial application. You are saying that a tester should use
the script interface of an application instead of banging away at the GUI
with a hard-to-configure test tool. Fine: Provide an application (for
download), even a simple one, with a GUI and a script interface, that is
ready to be tested (but not yet deployed). Provide a GUI script that blows
up for some reason, and a Ruby script that calls the COM interface instead
and actually finds a bug. Although contrived, it would at least provide
prima facie evidence that the thesis is worthy of further investigation.
Just automating Word using win32ole proves nothing about your contention.

I hope that is more helpful. :)

-- Bob.
--
"Act always so as to increase the number of choices." -- Heinz von Foerster