This is a multi-part message in MIME format.

------extPart_000_0007_01C1E933.B921D290
Content-Type: text/plain;
	charsets-ascii"
Content-Transfer-Encoding: 7bit

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

------extPart_000_0007_01C1E933.B921D290
Content-Type: text/html;
	charsets-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2462.0" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=458421919-21042002></SPAN><FONT color=#ff0000><FONT ace=Arial><FONT size=2>B<SPAN class=458421919-21042002>rian:</SPAN><SPAN 
class=458421919-21042002>&nbsp;</SPAN></FONT></FONT><BR><SPAN 
class=458421919-21042002><FONT face=Arial 
size=2>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 size=2>See 
comments in red...</FONT>&nbsp;</SPAN></DIV>
<DIV><BR>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&nbsp; leave the level of Ruby detail about the same. <BR><BR>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.<SPAN class=458421919-21042002><FONT face=Arial color=#0000ff 
size=2>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=458421919-21042002></SPAN>&nbsp;</DIV>
<DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 size=2>My 
only point is that you cannot use a script interface that is itself untested to 
test&nbsp;functionality that that also happens to be&nbsp;accessible through 
the&nbsp;GUI.&nbsp;You must test the GUI independently&nbsp;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&nbsp;GUI&nbsp;with a given 
automated test tool&nbsp;in the circumstance that there are custom object 
headaches to contend&nbsp;with&nbsp;is not a factor in the need to test the GUI 
somehow, separately&nbsp;from the scripting interface. It must be done, manually 
if necessary.&nbsp;That was the gist of my concern with your approach. 
Now&nbsp;having said that I do think there is value in testing the interface 
itself through scripting.</FONT>&nbsp;<FONT face=Arial color=#ff0000 size=2>Just 
not as a substitue for GUI testing, however you choose to do 
it.</FONT></SPAN></DIV>
<DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 ize=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 size=2>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).</FONT></SPAN></DIV>
<BLOCKQUOTE class=cite cite="" type="cite">
  <DIV>&nbsp;This is the first time I've used win32ole and only the second time 
  I've talked programmatically to Word. <FONT face=arial color=#0000ff 
  size=2></FONT><BR><BR><FONT face=arial color=#0000ff size=2>Do you wan't the 
  truth? It kinda shows... :(</FONT><BR>&nbsp;<SPAN 
  class=458421919-21042002><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=458421919-21042002>&nbsp;</SPAN><BR>I'd appreciate 
  suggestions for improvement, keeping in mind that I'm writing for a novice 
  audience.<SPAN class=458421919-21042002><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 ize=2>4&nbsp;points:</FONT></SPAN></DIV>
<DIV><SPAN class=458421919-21042002><FONT 
color=#ff0000></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=458421919-21042002><FONT face=Arial color=#ff0000 size=2>1. I'm 
sorry that came out as badly as it&nbsp;did.&nbsp;I apologize for the 
tone.</FONT></SPAN></DIV>
<DIV><FONT color=#ff0000><SPAN class=458421919-21042002><FONT face=Arial 
size=2>2. There weren't any specifics&nbsp;</FONT><FONT face=Arial size=2>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&nbsp;description of OLE as a logical 
"or" to COM suggested that you yourself did not understand that OLE is a echnology built on top of COM (like other technologies, such as structured 
storage, ADO, and so on), not just another name for it. 
</FONT></SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002>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&nbsp;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,&nbsp;engage in them with clarity 
of thought and a flare for analogy, metaphor and lots of handy sample 
code.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002>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&nbsp;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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#ff0000 size=2><SPAN 
class=458421919-21042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002>I hope 
that is more helpful. :)</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#ff0000 size=2><SPAN 
class=458421919-21042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#ff0000 size=2><SPAN class=458421919-21042002>-- 
Bob.</SPAN></FONT></DIV>
<DIV>--</DIV>
<DIV>"Act always so as to increase the number of choices." -- Heinz von 
Foerster</DIV></BODY></HTML>

------extPart_000_0007_01C1E933.B921D290--