User Kai Schrimpf ( posted:


it's hard to explain something you have been using for ages. I just use functions because i always did. Having to explain the reasons for it was very strange for me. But your EMail did the Job....

Gut "Druck" in Heidelberg,
Kai Schrimpf
---------------------------------------- Message History ----------------------------------------

From: "Schoen, Torsten 3865 PPE-QA1" <> on 05/10/2001 10:00 AM ZE2

Please respond to "SQA Suite Team Test Users" <>

To: "SQA Suite Team Test Users" <>
Subject: RE: SBL's v's Record & Playback

Hi Ian,

ok, here is a real life example of why you should use functions.
In one of our applications we have a screen with 5 comboboxes, with the
options listed in the later changing according to the settings made in
former ones (settings in CB 1 affect options in CB's 2-5...).
After these settings have been made, the same processing takes place in
every case.

The available options will usually change from version to version, also
might change from server to server. Testing all combinations would require
more than 10k iterations, but we limit this to some 1500-2000 cases, that
have to be evaluated manually.

Now doing that with record-playback just doesn't make sense. You would
record 2000 scripts that would undergo changes for every version of the
software, and sometimes even between builds (eg. when caption changes from
project name to the actual release name). Recording would be a tedious task,
playback due to failures a nightmare.

We set up 2 scripts for all this stuff. the first script reads all
combinations from the comboboxes and dumps the data to an excel file, the
second script reads excel tables and does the processing. All we need to do
is maintain 2 scripts, and as we use variables for the captions, etc. the
scripts only need to be changed in one place.

Most of the stuff was done directly in the script files, no librarys were
used in the beginning. But we need access to excel tables quite often, so we
set up a library with some excel functions that we can use in all our
scripts (thanks to Andy T.). We encountered problems with the comboboxes in
Java, so we wrote wrapper functions that would deal with that and put those
wrappers in a library.

Now I can change 1 function to adopt all comboboxes in all scripts to a new
selection method in case mouse clicks won't work (and they didn't for a

What I currently do for every Javacombobox is to selct it with a mouse
click, do a partial match on the available options, determine the index of
the matched entry, get the current options index, calculate the number of
{down} or {up} I need and use the keyboard to do the selection. Then I tab
out of it to commit the changes and move on to the next command.

All this would not be neccessary if either the developers would program to
robot's liking or robot would work as Rational Sales Team proposes. Actually
I have found that usually neither of these happens and the road of testing
is rather stony and full of traps.

Basically the main purpose of libraries is to effectively work around traps
and to reuse code needed in several places. No way to do any serious test
automation without them.


Torsten Schoen
Heidelberger Druckmaschinen AG