A FAQ - Frequently Asked Questions

Yes. Please visit www.qftest.com/en/product/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 trial license valid for two weeks by filling in the request form at services.qftest.com/en/license/request/.

License types and prices for QF-Test are listed at www.qftest.com/en/product/pricing.html.

No, not necessarily. QF-Test handles multi-user license management for local networks by itself, provided that IP multicast works. For floating licenses across multiples sites and in case of restricted networks, a dedicated license server is available. The license server itself is free of charge and server licenses are very reasonably priced. For further information about the license server, please get in touch with QFS via sales@qftest.com.

• Before asking for help, please read through this FAQ or the general FAQs www.qftest.com/en/product/faq.html to see if your question has already been answered.
• For beginners the learning-by-doing tutorial www.qftest.com/doc/tutorial/en/firsthelpweb.html or the instructions for getting started with QF-Test www.qftest.com/en/get-started-with-qf-test.html should prove useful. Further questions might also be answered by the manual.
• Videos for beginners and advanced learners can be found at www.qftest.com/en/support/videos.html.
• There is also a blog at www.qftest.com/en/blog.html containing lots of helpful postings (full text search is possible).
• During evaluation of QF-Test you are entitled to free support. Navigate to the QF-Test "Help" menu and choose "Contact the support team..." or use the web form.
• Customers holding a Software Maintenance Agreement with QFS also profit from above support options. (For details refer to our website).

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 on our website.

Enhancement requests are welcome anytime at support@qftest.com.

Simply contact our support team and we will have a look. Please be sure to provide as much information as possible, especially test suites and run logs.

As the first step, please ensure that really nothing has changed as automatic updates of Java or browser versions may happen without being recognized.

Irrespective of changes there can be tests that fail only occasionally for no apparent reason. This may sound like a bug in QF-Test, but that's rarely the case. In complex, multithreaded environments, many actions and interactions depend on timing. The first thing to try is to introduce delays at critical points. If that helps you can focus on minimizing the delay by using Check nodes with a timeout or Wait for component to appear nodes to wait for a certain condition.

If delays don't help you need to dig deeper and try to understand what's happening. It's not unlikely that the root cause is a bug in your application - typically a tricky one that shows only occasionally depending on timing or other circumstances. The blatant, obvious bugs are typically found earlier - these tricky ones are part of what testing is all about. The detailed logs and screenshots that QF-Test creates help analyzing such situations. Our support can help you interpret the data and isolate the relevant information to forward to development.

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 Test execution, Command line arguments, Exit codes for QF-Test and Interaction with Test Management Tools 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-Xmx1280m (or an even greater value; QF-Test uses up to 1024 MB by default). On Windows you can alternatively use the QF-Test Java Configuration tool, available from the Windows system menu. On Linux rerunning the QF-Test setup script (setup.sh) also lets you adapt memory usage. Of course the amount of memory you can use depends on your computer. Please refer also to "Installation and startup" for further details.

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 "Split run logs" 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.

GUI testing requires an unlocked, active desktop. That is the only way to ensure that the SUT behaves the same as if a normal user interacts with it.

To make sure that your test environment complies with this requirement, you'll probably need to tweak its setup. This holds true notably for continuous integration and build tools like Jenkins (c.f. "Integration with Development Tools"). Otherwise, you might run into serious trouble during Test execution, for example black screenshots in the run log (c.f. "The run log"), failing drag-and-drop operations, non-working hard mouse events or even problems during component recognition (c.f. "Components"). Java WebStart applications fail to start up. Chapter Hints on setting up test systems contains useful tips and tricks to set up your test systems.

Before running a GUI test, check whether the following conditions are met:

• QF-Test and the SUT have to run within an active, unlocked user session.
• The Test must not be executed within the Windows service session. It also must not run without an user session.
• During the Test execution with Jenkins you have to ensure that the Jenkins Windows node does not get started as service. It has to be started either via Windows Autostart or Windows Task Scheduler within a real user session. Please ensure that you select a valid user account at the 'Security options' and that you have 'Run with highest privileges' disabled. The selected user must be logged in during test execution, e.g. by automatically logging in, and the desktop must not be locked in any way.

• RDP connections must not be minimized or closed, that would result in a locked session. Instead of RDP you should use VNC, Teamviewer or similar tools to observe the running tests. RDP must not be used for the initial user login and start of the related session.

  NoteOn Windows 10 or Windows Server 2016 systems you can make use of RDP if you modify the Registry. Therefore navigate to HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client or HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client and add a new value RemoteDesktop_SuppressWhenMinimized as DWORD having the value 2. Once that setting has been set you are allowed to minimize RDP connections, but you have to keep the connection alive. The tests will still fail if you disconnect or close the session You can find further details about setting up your test systems in the manual at "Hints on setting up test systems" and "Test execution".

Technical background:
The keywords are 'session 0 isolation'. This means that every user has its own session ID, starting with 1. The session with ID 0 is reserved for services and applications without user context. It is restricted in its functionality and applications which run in this session are isolated from other sessions. Applications with GUI cannot be displayed within this session. When running a GUI application in the service session, it will not be rendered correctly and thus may not behave as expected. If you search for 'session 0 isolation' with your preferred search engine you will get extensive information, especially for Windows Vista and newer.
Due to security reasons, the well-known workaround for Windows XP and Windows 2000 via tscon.exe and redirection of session 0 is not working anymore since Windows Vista.

To get round all that problems you should consider to work with virtual machines, especially from a security point of view. If you execute the tests on a virtual machine, the above-mentioned requirements apply for this virtual machine only, not for the host. You can lock the host and don't care about session management on the host.

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, Groovy and JavaScript, put them in a jar file and place that in QF-Test's plugin directory (see "The plugin directory").

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")
  JavaScript:
  import {UserException} from 'de.qfs.apps.qftest.shared.exceptions'
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 https://wiki.python.org/moin/PythonEditors. There are probably dozens of suitable editors with syntax highlighting for Jython, Groovy and JavaScript - jEdit (www.jedit.org) is only one of them.