2018 up to now | 2017 | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 | 2009 | 2008 | 2007

(older archive entries before 2007 are not shown here, but included in the onsite-search)

Mailing List - Entries of 2007

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [QF-Test] How to manage the Description of smoke tests and their actual implementation

  • Subject: Re: [QF-Test] How to manage the Description of smoke tests and their actual implementation
  • From: Martin Moser <martin.moser@?.de>
  • Date: Tue, 17 Jul 2007 10:13:21 +0200

Hi all,

the description of Mark is quite good and I would have answered something
similar :-)

.) Data-driven Testing
Data-driven testing shouldn't be a big problem with QF-Test because of
these nodes. I think it's also described in the manual (chapter 12), but
has no separate example. I can send you an example, if you want. But you
don't need to do much programming with data-driven testing.

.) Keyword-driven Testing

The tricky thing is to recognize that nearly all values in QF-Test's nodes
can be replaced by variables, so also the procedure-call values, which Mark
also explained already.

The easiest way of keyword-driven testing is really to read the procedure
names as test-data, like you've mentioned already. You can also read only
parts, like Mark showed. If you name the parameters the same as the
test-data values, you don't even need to specify the variables at a
procedure-call, because they are put on the variable-stack via the
data-driver. So you don't need too do a lots of programming. Programming
has to be done mostly for certain actions in your application, like
selecting all entries in column 'a' with value '6'.
With try-catch and dependencies' catch nodes you have also some powerful
possibilities for error-handling and rollback steps in case of failing

Another approach, which can be combined with this, is the approach of
"generic" components, which also makes the component-recognition
variable.Please see <http://www.qfs.de/archive/qftest-list/2006/msg00219.html>


--On Dienstag, Juli 17, 2007 08:13:43 +0200 Wiesner Stephan
<stephan.wiesner@?.ch> wrote:

Good morning Martin,
that sounds very interesting. I am used to do something similar (data-
and keyword-driven testing) with other tools, but had already given up
with QFTest. I just can't seem to figure out how to do some serious
programming with it. I am a Java developer turned tester and hate Jython
and am certainly not going to write complex scripts in the text editor
that is part of QFTest. And though the integration of Java works, I am
not really comfortable with it. To be honest, my choice of tool would
have been Rational Functional Tester, for the given reasons.  I have to
admit, that QFTest is _much_ more easy to use and does an excellent job
for simple capture replay testing. That is why we use it and that is why
we use it only for smoketests.

So, how do you work with your data from the CVS files? Do you simply read
in the procedure names, call those procedures and provide data from the
rows as input to those procedures? Or did you have to do a lot of
programming (how) to process the input?

Sonnige Grüsse aus Bern,
Stephan Wiesner

Testmanager ESTM
Telefon +41 (0)31 551 78 68

RTC Real-Time Center AG
Schwarzenburgstr. 160
3097 Liebefeld

-----Ursprüngliche Nachricht-----
Von: Martin Moser [mailto:martin.moser@?.de]
Gesendet: Montag, 16. Juli 2007 17:14
An: qftest-list@?.de
Cc: Wiesner Stephan
Betreff: Re: [QF-Test] How to manage the Description of smoke tests and
their actual implementation

Hello Stephan,

it seems, that nobody wants to share their knowledge with you.

I visited some customers, which did an integration with QualityCenter and
QF-Test and started QF-Test right out of QualityCenter, so they had also
the linkage between QF-Test and the test-case description. Some of them
used the direct batch-call, others the daemon-mode.

I personally like the idea of combining data-drivers and modularized
implementation of test-cases. So, what I do, is that I make very
low-level  procedures via Capture&Replay, which do only small steps in
the GUI. Then I  read the test-data via a data-driver node from a CSV
file or from  Excel-file (example should be on the mailing-list,
otherwise contact me).  Some of the test-variables contain names of those
low-level procedures. So  I abuse test-data-sources as test-command
structuring parts. The efforts  for this approach is, that you've to
create the low-level procedures and a  proper test-data file structure
first, where I'm investigating some smart  solutions for future versions.
Changes in the UI have to be updated in the  according procedures later,
but with a proper naming-scheme you could avoid  touching the data-files.

Perhaps some other people want to share their approaches, ...


Martin Moser                           martin.moser@?.de
Quality First Software GmbH            http://www.qfs.de
Tulpenstr. 41                          Tel: +49 8171 919874
DE-82538 Geretsried                    Fax: +49 8171 919876
GF: Gregor Schmid, Karlheinz Kellerer  HRB München 14083