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: "Wiesner Stephan" <stephan.wiesner@?.ch>
  • Date: Wed, 18 Jul 2007 11:05:21 +0200

Moin Moin Mark,
merci for your reply. I did know how to implement DDT with QFTest, but your mail offered some additional information that I find very helpful. I am certainly going to play around with your ideas.

Freundliche Grüsse,
Stephan Wiesner

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

RTC Real-Time Center AG
Schwarzenburgstr. 160
3097 Liebefeld

-----Ursprüngliche Nachricht-----
Von: Michaelis, Mark [mailto:mark.michaelis@?.com]
Gesendet: Dienstag, 17. Juli 2007 08:55
An: Wiesner Stephan; Martin Moser; qftest-list@?.de
Betreff: RE: [QF-Test] How to manage the Description of smoke tests and their actual implementation

Hello Stephan,

DDT Testing is really a piece of cake using QFTest:

1. Create a DDT Node
2. Either enter data directly or use a CSV file (e. g. username/password)
3. Create a test case node below the DDT node
4. Reference variables from the DDT Node (e. g. ${username})

Of course you might also decide to call procedures via "reflection" using this mechanism. I for example have a variable _actiontype_ with values like "mnemonic", "shortcut", "menu", "mouse", ... For a procedure openFile I then use:


Well, my scenario is more complicated but it can be reduced to this.

The great thing about this: This makes it easy and quick to generate new test cases and they are very easy to read as there are less nodes to read. And what I really like in QFTest: You can comment every node. Or you can put sequences of nodes in sequence nodes and label them in a way that makes them easy to understand.

>From my point of view you can write tests which are even readable for non-testers. My tests e. g. look like this directly below the test node:

* Sequence: Set Variables
* Sequence: Open File
* Sequence: Edit Content
* Sequence: Save File
* Sequence: Checks
  * Sequence: Check File Data (Size, Modification Date)
  * Sequence: Check File Content

I. e. with one view you can get an idea of the whole test. You don't have to worry to go into details if you just want to see what is actually tested.

About the Java Integration: I also don't feel comfortable with integrating Java through libraries into qftest. From my point of view you suddenly have to compile, build jars, set classpaths etc. I think it's harder to maintain such tests.

I rely on small chunks of Jython placed in external files. Inside qftest I only store 1 to 4 lines of Jython Code. Many Jython Code is placed in something I call a "framework" i. e. hidden from most developers.

Only small parts of Java Code are directly "injected" into a GuiTestFacade which comes with the SUT. I use the classloader of the application to locate the GuiTestFacade and create an instance of it. This way I am close to the application and every developer of the application is either aware of the interface I use for GUITests or at least I am indirectly informed in case of refactorings as I know where to search.


Mark Michaelis
Software Engineer Quality Assurance

Ludwig-Erhard-Str. 18
20459 Hamburg, Germany