From: Bob Calco Date: 2002-04-22T01:57:32+09:00 Subject: RE: article about testers using Ruby. This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1E933.B921D290 Content-Type: text/plain; charset="us-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 ------=_NextPart_000_0007_01C1E933.B921D290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Brian: 
 
See=20 comments in red... 

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

As=20 far as the testing topics go, you'll have helped me be more precise = about my=20 wording. But I don't yield on my claim that the combination of = automation=20 through a scripting interface and manual exploratory testing is a better = default=20 choice than automation with a GUI testing tool. That's not a topic for = this=20 list, though. 
 
My=20 only point is that you cannot use a script interface that is itself = untested to=20 test functionality that that also happens to be accessible = through=20 the GUI. You must test the GUI independently in any case = (if only=20 to prove that it actually accesses that lower-level functionality = properly);=20 whether it's feasible to test every aspect of the GUI with a = given=20 automated test tool in the circumstance that there are custom = object=20 headaches to contend with is not a factor in the need to test = the GUI=20 somehow, separately from the scripting interface. It must be done, = manually=20 if necessary. That was the gist of my concern with your approach.=20 Now having said that I do think there is value in testing the = interface=20 itself through scripting. Just=20 not as a substitue for GUI testing, however you choose to do=20 it.
 
In=20 other words, a professional test engineer cannot "shun" the GUI, however = much of=20 a pain in the butt it is to test, with or without an automated test = tool. You=20 *can* however supplement GUI testing with testing of more = programmatically=20 direct means of accessing application functionality, i.e., through a = script=20 interface (if the application even supports such an=20 interface).
 This is the first time I've used win32ole and only the = second time=20 I've talked programmatically to Word.

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