2018 bis heute | 2017 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: "Michaelis, Mark" <mark.michaelis@?.com>
  • Date: Tue, 17 Jul 2007 08:55:11 +0200

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

CoreMedia AG
Executive Board: Sören Stamer (CEO), Dr. Klemens Kleiminger (CFO)
Supervisory Board: Prof. Dr. Joachim Schmidt (Chairman)
Trade Register: Amtsgericht Hamburg, HR B 76277