Yes. Please visit www.qfs.de/en/qftest/download.html.

Normally a license file is required to run QF-Test. It will run without a license, but it will not let you save any files or load any files that were not provided by Quality First Software GmbH. This is sufficient for getting a first impression, working through the tutorial and making a first attempt at running your application under QF-Test. To go beyond that, you'll need a license file.

You can obtain a free evaluation license valid for 4 weeks by filling in the request form at www.qfs.de/cgi-bin/eval.

License types and prices for QF-Test are listed at www.qfs.de/en/qftest/license.html.

No. QF-Test handles multi user license management itself.

• Before asking for help, please read through this FAQ to see if your question has already been answered.
• For beginners the learning-by-doing Tutorial proves useful, further questions are answered by the Manual.
• Webinars for beginners every Monday 16:00 CEST. Registration via qfs@qfs.de.
• There is a mailing list for QF-Test questions and discussions that you can subscribe to (see www.qfs.de/mailman/listinfo/qftest-list). At www.qfs.de/archive/qftest-list the list archive is available which contains lots of helpful postings (full text search possible).
• During evaluation period of QF-Test we grant free support via email qftest@qfs.de or phone +49 (0)8171 3864820.
• For customers we offer support with a guaranteed response time in the form of our Software Maintenance Agreement (see www.qfs.de/en/qftest/support.html).

QF-Test trainings for beginners and advanced users in German and English language take place regularly here at QFS. There is also the option for webinar-based or on-site consulting and training. Details can be found at www.qfs.de/en/qftest/training.html.

Enhancement requests should preferably be sent to the mailing list (see above), but they are also welcome anytime at qftest@qfs.de.

Simply send an email to qftest-bug@qfs.de. and we will have a look. Please be sure to provide as much information as possible, especially test-suites and run-logs.

This is a feature. Please read chapter 6 about how names are set with setName() and why they are important. The warning helps to find components that don't have a name. It is not for general use, but the default setting makes people aware of the fact that the reliability of tests can be improved tremendously with little effort.

You can turn the warning off with the option Log warning for missing name.

You can run QF-Test in batch mode through the command line argument -batch. Many other command line arguments can be used to configure the test-run. The exit code of QF-Test reflects the outcome of the test. See chapter 16, section 32.2 and section 32.3 for details.

Yes, just start two SUT clients with different names. You can then control both of them.

To increase the available memory, start QF-Test with the argument -J-Xmx512m (or any other value, QF-Test uses up to 256 MB by default). On Windows you can alternatively use the QF-Test Java Configuration tool, avaialble from the Windows system menu. On Unix re-running the QF-Test setup script (setup.sh, setup.ksh) also lets you adapt memory usage. Of course the amount of memory you can use depends on your computer. Please refer also to chapter 1 for further details.

Note If the memory chosen is too high, Java will not start and therefore also QF-Test.

There are a number of ways to reduce the memory use of QF-Test:

• Make sure that the option Create compact run-log is checked so that all irrelevant nodes are removed from run-logs.
• QF-Test keeps 4 run-logs accessible from the »Run« menu by default. Keep the option Automatically save run-logs active so that QF-Test can save these run-logs to files and release their memory.
• Close run-log windows that you no longer need so that the memory for these run-logs can be reclaimed.
• For long-running tests the best option is to create split run-logs (which QF-Test uses as default) so QF-Test can save partial run-logs to files instead of holding the entire run-log in memory. See subsection 9.1.4 for details.
• If the option Don't create run-log is checked, no run-log will be generated at all. This should also be used with caution since it can be extremely difficult to interpret what happened without the help of the run-log. Use split run-logs instead.
• If your SUT prints lots of output you can reduce the number of old clients that are kept around by changing the option Number of terminated clients in menu.

You cannot get an object out of the blue, some kind of registry must exist that returns the object from a class static method. Typical examples in the standard Java API are java.lang.Runtime.getRuntime() or java.awt.Toolkit.getDefaultToolkit().

This is standard Jython stuff: Simply import the class and call its methods, e.g.
from java.lang import Runtime
runtime = Runtime.getRuntime()
In Groovy the package java.lang gets imported even automatically:
def runtime = Runtime.getRuntime()
You can access any class of your application the same way, provided the class is declared public. Note that you must use an 'SUT script' node, not a 'Server script' node.

To make additional Java classes available to Jython and Groovy, put them in a jar file and place that in QF-Test's plugin directory (see section 37.2).

There are two ways to do that:

• Jython:
  raise UserException("Some arbitrary message")
  Groovy:
  import de.qfs.apps.qftest.shared.exceptions.UserException
throw new UserException("Some arbitrary message")
• rc.check(condition, "Message", rc.EXCEPTION)
  will raise an exception only if the condition is false.

That's a matter of taste, to some even religion. A comprehensive list of editors for all kinds of operating systems that support Python syntax highlighting and other goodies is available at http://www.python.org/cgi-bin/moinmoin/PythonEditors. There are probably dozens of suitable editors with syntax highlighting for both Jython and Groovy - jEdit (http://www.jedit.org) is only one of them.