Keyword-driven testing is a modular way of creating readable tests. Acceptance tests basically consist of the same abstract actions (clicking, checking, selecting) and the same logical sequences (logging in, creating / deleting etc.) again and again. For each of these recurring sequences or actions, a reusable keyword is created. This makes it easy to create large tests by reusing keywords again and again. It also lowers the maintenance effort because changes at a central place update the whole test. Keyword-driven testing places importance on an initial planning stage, where the structure and design of the test are considered.

Once the keywords have been planned, they can be implemented. The advantage of using GUIdancer or Jubula for keyword-driven testing is that the implementation of keywords does not involve any programming effort, which saves time and resources, and gives testers full control over the tests. Once you have your keywords, you can combine them to form tests. It is also easy to create keywords after you have started writing tests, using our refactor function.

GUIdancer and Jubula are installed with a library of pre-designed keywords, which you can reuse in your project to speed up test creation.

Many tools produce program code as the basis for automated tests (e.g. capture-replay tools) or require that code be written to execute the test (many keyword-driven tools). This approach leads to large amounts of time and resources being spent to modularize and parameterize code and/or to write actions in program code. The test automation quickly becomes a project with a huge code base, which itself needs to be maintained, and even tested! Test progress is slow and many projects collapse under the weight of the unexpected work.

Writing tests in code takes a great deal of time. The actions that are executed have to be platform- and application-independent and they should be high-level, so that the tester is dealing with more than just a series of clicks in the application. Really, to write tests in program code means taking the time to think about a whole framework for test execution, including synchronization, error handling and results.

As a GUIdancer or Jubula tester, all this work is done for you. We have taken the time to design, create, maintain and test the code necessary to produce high-level actions which are understandable and usable by testers. Our actions are platform, application and toolkit-independent. They contain internal synchronization, error handling and deliver the results back to the tester.

The result is that test automation with GUIdancer / Jubula is incredibly productive. No time is wasted writing code for the test execution. All you need is already available and tests can be created simply using drag and drop. Avoiding any programming effort also has the benefit that tests are written completely from the user perspective, which is exactly the perspective that a functional acceptance test should consider.

The benefits of the GUIdancer / Jubula approach are:

• More productivity from the beginning and throughout the test project
• Testers are not reliant on the availability and input of automation experts or engineers
• Easy test creation and maintenance
• Readable tests

And, if you do want to add support for your specific components, you can do this using our extension mechanism.

Although GUIdancer and Jubula do have an observation mode to record actions in a running AUT, we do not consider ourselves to be a capture-replay tool, because tests can also be easily specified by drag and drop using our library of keywords. In addition, GUIdancer / Jubula has various benefits when compared to capture-replay tools:

• You can start writing your tests before an application is available. This means that tests can run as soon as an application is ready, so you find errors earlier, when they are cheapest to fix.
• Tests are modular and well-structured from the outset. There is no programming work to do to make tests maintainable. Even the observation mode produces readable Test Steps, which are easy to combine into reusable modules.
• The actions delivered with GUIdancer / Jubula are designed to be as abstract yet as high-level as possible, so that there are no unnecessary implementation details and no redundancy in tests. Similar actions can often all be tested with one keyword. This reduces maintenance and improves the flexibility of your tests.
• Writing tests before an application is available means that you concentrate on testing against the requirements, not against the implementation.

Yes, we automate our functional tests for the GUIdancer software (and for the actions we support) with GUIdancer itself.

Our main strength lies in our simple yet powerful reusability concept. We believe that tests should follow the same best practices that are used in software development -- but should not be written in code. This is why we place so much importance on modularity and reusability as the key to successful test automation.

GUIdancer / Jubula is a functional GUI test tool. You can test business rules, order-dependent use cases, interface scenarios such as activation of buttons/text fields, and text entry/checking actions. The tests are all done via the user interface. We are therefore not a load-testing tool.

Once you have installed GUIdancer / Jubula, you can expect your first tests to be up and running in a very short space of time. Even on the first day, you will have some basic tests for your application which form the start of a testing safety net which will grow quickly. You and your team do not need to spend time programming actions or functions, because everything you need to write tests is already available. And because GUIdancer / Jubula tests are modular and well-structured, even changes to your application or requirements should not slow you down.

If you try to connect to the AUT Agent and get an error message, make sure that you:

• Have started the AUT Agent from the start menu or via the command line
• Are trying to connect to the AUT Agent on the right port number. The AUT Agent preferences let you see and add port numbers.

You can test applications whose user interface is written with Java (Swing, SWT/RCP) and HTML. We also support RCP applications with GEF (Graphical Editing Framework) components.

GUIdancer and Jubula can start and test Java web start applications once the application has been downloaded and saved to the file system. However, the actual Java web start mechanism is currently not supported.

You can read the system requirements in our technical datasheet.

You can read about the software requirements in our technical datasheet.

GUIdancer and Jubula are tested with the Sun JRE. Because the GCJ/GIJ and OpenJDK Java runtime environments use a non-standard implementation, they are not supported.

To test RCP applications, you must unzip the RCP Remote Control Plugin into your application's plugin directory. Information on doing this is in the user manual.

If you install a new version of GUIdancer or Jubula, bear in mind that you will need to install the new RCP Remote Control Plugin too. The first time you start your application after installing the new plugin, start it with a -clean argument.

RCP applications also need to have a keyboard layout specified in the AUT configuration. The keyboard layout corresponds to the system regional settings. Note that the keyboard that is actually physically connected to the computer has no bearing on the test execution.

RCP applications generally have a configuration/config.ini file which contains the parameter osgi.bundles. This parameter may need to be modified to allow the RCP Remote Control Plugin to load on AUT startup. The org.eclipse.update.configurator plugin automatically loads all plugins found in the plugins directory, which means that the RCP Remote Control Plugin should start with the AUT if org.eclipse.update.configurator@3:start is already defined in the osgi.bundles parameter. Otherwise, you may need to add org.eclipse.jubula.rc.rcp to the end of the osgi.bundles parameter.

GUIdancer and Jubula tests operate on a toolkit basis. A toolkit is a GUI framework. The toolkits we support are: Swing, SWT, RCP, GEF and HTML.

When you are testing SWT and RCP applications, you'll need to specify a keyboard layout in the AUT configuration. This tells GUIdancer or Jubula what layout your system is using. Note that the actual keyboard attached to the computer does not make a difference; the system regional settings are what counts.

If your application uses a keyboard layout which is not supported out-of-the box, you can create a keyboard mapping file and add this to the tool. Information on creating the keyboard layout and where to add the finished file is in the reference manual.

At the moment, there is no direct support for integration with such tools. However, test projects can be exported in xml format, which makes it easy to manage and administer projects in various tools.

You can also use a unique ID for your Test Cases to reference them in external programs and to search for them in your tests.

In the GUIdancer tool (enterprise version of Jubula), you can view test result trends over time using the BIRT engine.

Yes, we are compatible with both UTF-8 and UTF-16 applications. This means that you can even test Japanese or Chinese versions of your application, for example.

There is no direct support for database access as a Test Step within GUIdancer or Jubula. However, external scripts can be executed as a part of a test. Also, database query results can be stored in an Excel table, which can be used as a data source in the test.

If you want to add support for database queries, you can do this by writing an extension.

You can add support for your own components and actions using the extension API. Support can be added for the toolkits Swing, SWT and RCP, but not for Web. Instructions and details on doing this are in the Extension Manual. Extensions are written in Java.

A step-by-step execution is not possible, but there is the option to pause a test if an error occurs so that you can analyze errors as they happen.

Yes, we have a command line client called the Test Executor which allows this. The use of the Test Executor is described in the user manual.

You can also run tests on the AUT using a virtual frame buffer if you want the testing to take place independently of the actual GUI environment.

There is no direct ant target for executing GUIdancer or Jubula. However, the exec command can easily be used, for example:

< exec executable="GUIdancerCMD.exe" vmlauncher="false" failonerror="false" resultproperty="testResult" />

We recommend using a tool or framework for continuous build integration. This tool can then execute tests and evaluate the results.

We use Hudson as our continuous build integration framework. Hudson runs on a dedicated test computer, which has a stable environment and configuration. Our tests are run from this machine, with AUT agents running both locally and on other remote test machines. Hudson:

• checks out the source files from the repository,
• builds the application,
• starts the tests, and
• reports the test results.

The most basic smoke tests are run after commits throughout the day, more complex tests are executed every night, and tests with very long execution times are executed over the weekend. In this way, defects can be identified within a short time after they are committed to the repository.

We require various ports to communicate in two directions:

• From the client to the AUT agent: this port is defined in the preferences.
• From the AUT to the client: this port is dynamically chosen, and cannot currently be defined. Therefore, any ports available on your test machine must also be open on the machine from which the test is being run.

If opening all ports in this way is not an option, we recommend using the command line client on the test machine to run the tests, so that all communication is done locally.

You can test different AUTs during one test using a ''Test Job''. A Test Job allows you to combine multiple Test Suites to be executed after each other. Each Test Suite can be linked to a different application.

The best way to get an overview is to look at the topics in the welcome page, and then to do the cheat sheets (via the Help menu in the Integrated Test Environment. They will guide you step-by-step through your first test.

Bear in mind that GUIdancer / Jubula is a powerful tool, which supports reusability. For this reason, it is a good idea to think about your test structure before starting.

Tests in GUIdancer / Jubula are made up of ''building blocks'' (Test Cases, keywords, modules). Once a Test Case has been specified, it can be reused again and again. The advantage of this is the increased structure your tests will have. The more you reuse, the easier your tests are to maintain because one central change will update a number of Test Cases.

We support reusability by offering various ways to keep your Test Cases flexible. Obviously, the more general a Test Case is, the easier it is to reuse in a variety of situations.

We recommend keeping data separate from the Test Case, by using references in place of parameter values. You can also change the component a Test Case tests, to reduce the amount of Test Cases you need overall. We also support abstract components to keep your tests even more flexible. Use the library of pre-defined Test Cases installed with GUIdancer / Jubula to create structured, maintainable tests easily using drag and drop.

We have various ways of helping you to work with GUIdancer or Jubula:

• Press F1 to get context-sensitive help
• Use the help menu to open the user manual or reference manual in a browser, to search the topics
• You can find support through the Jubula community on the Jubula website and can order professional support for Jubula and GUIdancer from the BREDEX website.
• BREDEX GmbH also offer training and consulting for Jubula and GUIdancer.

Abstract components are general components which leave the exact implementation open. Whereas ''concrete'' components are restricted to one component type (e.g. Table, Tree), an abstract component includes various components which all offer the same actions on similar objects. For example, you can use the ''component with text'' to check the text in a wide variety of components.

Using abstract components increases the reusability of your test cases, because they are initially very general, and the actual component is not set until you map it. You can also increase the maintainability of test cases using abstract components - if you have specified a test step to enter a value into a ''component with text input'' then it does not matter if the component in the application changes from a text field to a combo box, for example, as both components are included in the abstract component.

A rule of thumb: be as abstract as possible, but as specific as necessary when specifying tests.

GUIdancer and Jubula use the user interface in the same way as a real user would. Because of this, we use a great deal of high-level actions on components (e.g. on trees or menu bars) which require a path as a parameter. A path is simply the steps you follow to get to a particular menu item or tree node. You can generally choose between entering a path based on its content, or textpath (e.g. File/Edit) or based on the position of the elements, that is, the indexpath (e.g. 1/2).

All paths in GUIdancer or Jubula use slash ('/') to separate elements. The index for the first item in a main or submenu/node is '1'.

Context-sensitive menus are opened by right-clicking at a certain place in a component. The content of the menu depends on the place you click and on the state of the application. GUIdancer and Jubula use exactly the same method to open context-sensitive menus. You specify which component you want to open the menu on and choose an action to open the context-sensitive menu.

If you want to open a context-sensitive menu from a particular node in a tree, for example, navigate first to the node (using a select node action), and then use the action to open a context-sensitive menu. There are various options about where to open the menu and how to choose a menu item. You then give these details as the parameters for the action. You map the test step by joining it with the name of the component you are opening the menu on (e.g. Tree, Table).

In the example above, the context-sensitive menu has been opened on a tree component. The textpath to the node on which the menu was opened is Project/Test Suite. The path to the selected menu item is Delete.* (using the matches operator).

Your tests will be more robust if you use regular expressions to deal with text in your application. For example, when you want to perform actions to select or check in:

• Menus
• Trees
• Tabbed panes
• Other components with text

Use the parameter value matches or simple match for the ''operator'' parameter. ''Matches'' means that you can use regular expressions in the text string. ''Simple matches'' is an easier way to incorporate wildcards. With ''simple matches'', use the star symbol (*) to designate a wildcard (e.g. Project*).

GUIdancer and Jubula are installed with projects containing elementary Test Cases which cover all actions supported by the program.

Simply select the Test Case you want to reuse from the library and drag it to the place you want to reuse it. Enter the parameter values in the Properties View, and enter meaningful component names in the Component Names View.

You can use Event Handlers to deal with errors and occasional pop-ups in your test. Event Handlers are Test Cases that spring into action when an error occurs. If a Test Step fails, for example because of a pop-up, you can specify an Event Handler to close the pop-up (using Alt+F4, for example) and then continue with the test.

There is a cheat sheet on using Event Handlers in the Help menu in the GUIdancer and Jubula applications.

GUIdancer and Jubula let you deal with native dialogs (e.g. file choosers) and other native elements during the test by using the actions external key combination and external text input (on the ''application'' component) to enter text and send keyboard commands.

For convenience, you can also use the action Copy to clipboard followed by Ctrl+V as a key combination (all on the ''application'' component) to enter text and filepaths into native dialogs.

Test Cases to check properties are the same as any other Test Case. Choose the component you want to check (e.g. a component with text) and select the check action you want to execute (e.g. check text). Enter the text to be checked as a parameter. Remember that using regular expressions for text will make your tests more robust.

Checking for empty strings can be done in one of three ways:

• With the operator matches, enter '^\s*$' or '^$' (including single quotes) as a parameter
• With the operators equals, matches or simple match, enter '' (two single quotes) as a parameter

Use backslash to escape single symbols (in some cases you may even need two backslashes). If you want to enter a whole string which contains a variety of special symbols, use single quotes around the string (e.g. 'String').

The reference manual contains more information on special characters.

With GUIdancer or Jubula, it easy to construct cases such as:

• "Wait until the text Loaded appears in the status bar"
• "If the checkbox isn't selected, then select it"
• "If this action isn't successful the first time, take some (or no) action and try again." The number of tries can be configured.
• "If this action isn't successful, then execute some other action(s)." The action(s) executed after the error can be any actions - for example taking a screenshot or restarting the application.

There is a known issue with using Excel worksheets as data sets. Entering true or false in an Excel cell is automatically converted to a boolean value in Excel. This is then not readable by GUIdancer or Jubula in the test execution.

To combat this problem, make sure that the column in Excel has the format Text. The values will then not be interpreted by Excel as boolean, and GUIdancer / Jubula can read them in the test execution.

Yes, you can translate your test data into any languages supported by your application so that your tests can run for different language versions of your application.

The restart action from the Test Case library ends the AUT using java.lang.Runtime.exit(). If your application does not respond well to this, you could add a hook in your application (java.lang.Runtime.addShutdownHook()) which is called before the exit takes place and takes care of anything that needs to be done to make the restart work correctly (disconnect from DB etc).

GUIdancer and Jubula support various components, e.g. trees, tables, combo boxes. When you are in the object mapping mode, these components have a green border, and can be mapped. You can only map the components supported by GUIdancer / Jubula.

If you specify a Test Step to execute an action on a tree, for example, you have to map the ''tree'' component from the application. How you navigate through the tree (where to click, what to select) is given as parameters for Test Steps.

Similarly, tabbed panes are mapped as the whole pane. To select a specific tab, enter the tab name as a parameter for a Select Tab Test Step.

There is a known problem with an environment variable which is installed with certain products, including other test tools, and may not be removed when these products are uninstalled. The variable is called ''_JAVA_OPTION'' and causes problems for GUIdancer / Jubula and possibly also for other Java-based software.

To see if this variable is installed on your computer, right-click on the ''My Computer'' icon on your desktop and select ''Properties''. In the dialog which appears, select the ''advanced'' tab and, at the bottom, click on the ''environment variables'' button. You will see a list of environment variables on the computer. If the ''_JAVA_OPTION'' variable is present, and you have uninstalled the program which used it, then you can simply remove the variable.

No, you must not have any other tables from any other programs in the database you are using for GUIdancer or Jubula. Do not add the GUIdancer / Jubula database tables to another schema, and do not add tables from another schema to the GUIdancer / Jubula database.

There is a known problem with the interaction between Eclipse and Logitech mice. Specifically, the program SetPoint.exe, which is installed with many Logitech mice, can lead to wizard pages being blank. Stopping the SetPoint.exe and restarting Eclipse (or GUIdancer / Jubula) solves the problem.

More information on this can be found on the Eclipse Bugs site.