2017 bis heute 2016 2015 2014 | 2013 | 2012 | 2011 2010 2009 | 2008 | 2007

(ältere Archiveinträge vor 2007 nicht dargestellt, aber in der Suche enthalten)

Mailingliste - Einträge 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: "Wiesner Stephan" <stephan.wiesner@?.ch>
  • Date: Tue, 17 Jul 2007 08:13:43 +0200

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, ...


Videos Downloads Dokumentation Kaufen Gratis Testen