Latest Versions of TestBench Enterprise

The views no longer open within the client window, but as separate windows of the operating system.
Switching between the windows can be done via ALT-TAB. From all windows, all windows are accessible via the respective status bar.
Assigning elements via drag & drop is done across windows, even across multiple screens.
The windows have a progress display and are restored exactly (size, position, screen) when the client is started.

Versions of test case sets and test elements can be compared. The result is opened in the browser as a web page.

The comparison and the content to be compared can be set individually.

A plugin can be defined for the specification and the execution respectively, which appears as an additional button in the management information of the specification and under the buttons for starting the manual test execution.

The plugin can be executed directly without indirection via these buttons.

To display the structure of elements, they can be dragged into the browser.
All displayed elements can now be assigned from the browser anywhere.

In the browser, the first characters from the description of the textual test steps are displayed as the name.
(Same functionality as in iTORX)

Default values can be set for parameters in the parameter lists of test case sets and interactions.

If new test cases are created for test case sets, the default values from the parameter list are used instead of the "red ?".

When interactions are called in test sequences, the default values are also used instead of the "red ?".
In test sequences, the default values from the parameter list of a called interaction can be set directly via keyboard shortcut CTRL-M.

If another default value is set, all values preset with the default value also change.

A new test element, the reference data type, allows references (attachments, file references, hyperlinks) to be used directly as representatives.
Reference data types are atomic data types whose representatives can be used in the same way as the representatives of the standard data types.

The representatives of the reference data types can be distinguished from normal representatives by a preceding icon.

In addition to the description, interactions can manage other information. The content is given a type so that it can be better displayed and processed externally.

In these advanced contents, e.g. control data or code snippets can be used in test execution.

For a better overview, the versions and usages for test elements are now on the same tab card.

Furthermore the following was added:

• Information about the version
• Accessible visualization of the loaded version
• Change marker

In the test element view, all its uses can be displayed for a test element. The uses are displayed for all versions of the test element.
For each usage, it is also shown whether the usage lies within or outside the associated subtree. For data types, the usage of its representatives is also taken into account.

The detailed uses can also be displayed for all elements of a subdivision. In this way it can be determined, for example, whether a subdivision can be deleted or whether there are still uses outside the subdivision.

If the parameter of a test case set is subsequently converted from an atomic instance to a detailed instance, the values of the underlying subdata types are entered in the test case table.

The same applies accordingly to the conversion of a detailed instance into an atomic instance.

For values with certain semantics it makes sense not to define these values again in each data type, but to have a possibility to define these values at a central place.
Such a value can be e.g. the "explicit empty value", so that everywhere uniformly a value can be set to explicit empty.

Another new test element, the global data type, is used for this purpose. Its representatives can be selected in the selection lists of other data types of the same test object version. For this purpose, the use of the global data types must be allowed for these other data types.

Test elements (interactions, data types and conditions) can be centrally grouped in libraries within a test object version. These libraries can be used in other test object versions.

The basic functions are:

• Consistent stands of the elements of a library are created and versioned as baselines.
• Updating to new versions (= new baselines) of a library is possible.
• The test elements of a library are read-only in the test object version being used, so they can only be changed centrally.
• Libraries can have dependencies on other libraries.

Requirements management displays metrics for baselines on the coverage of requirements by tests and the distribution of the test status of requirements.
If multiple baselines are present, the metrics are also output over all baselines in total.

In the context menu of a metric the graph can be saved or printed.

The ID of a requirement can be shown in the tree of requirements.

The ID of a requirement, compared to the title, is more often used to identify a requirement and now can be seen directly.

In each test theme, the distribution of the status in the subtree is displayed.
Inside the context menue of the metric the graphic can be saved or printed.

For the root of the test theme tree, the Current View, the status distribution is displayed for the whole tree.

The colors of the graphics can be adjusted for each client.
In the clients "bin" directory the file "nimbus.properties" exists in which the colors are defined.

Suggestions for the different color deficiencies are stored, which every user can adapt individually to his needs.

Deeply nested trees often contain many different filters at various positions on the trees. The position of a filter can now easily be found in the tree.

Double click on the filter name jumps to the definition of the filter in the filter administration.

Loaded or (locked) versions checked in by the system can be checked out immediately, switching to the version list is no longer necessary.

In these cases the check-in button changes to a check-out button.

The details of a requirement are displayed directly in the test specification. The switching to the requirement management can be omitted.

This is valid for requirements for test themes and test case sets.

The table titles of the parameters in the test sequence adapt to the parameters of the selected line.

The parameter names of the called interaction are displayed, which are also shown in the tooltip of the parameter.

Test sequences of textual test steps can be entered and edited completely via keyboard.

Also applies especially to test sequences mixed of interactions and textual test steps and the commentary columns.

Test steps in test sequences can be replaced using drag & drop or the context menue. This also works for textual test steps.

The same parameters are reused from left to right.

The browser is used to visualise structures in the Keyword Driven Test and in the Data Driven Test. Jumping to the displayed elements is now possible.

The existing functionalities are now also accessible via the context menu.

With Drag & Drop you can "wait" over tree elements, so that they open their detail view and elements can be inserted directly into it.

This has always worked for all tab cards and the expanding and collapsing of trees..

Interactions used in test sequences of test case sets can be identified in the auxiliary objects view.
Double click on the name has the same function as the context menu.

Double click in the number column jumps to the element in the test design view.

Instances can now also be copied between instance tables using <CRTL> and drag & drop or the keyboard via <CRTL>+X and <CRTL>+V.

As before, drag & drop moves the instances between instance tables.

In the selection dialog for representatives of a generic parameter now you can sort and search.

Sorting is done via the column titles.

The data of the selected test cases in the test execution can be copied as a semicolon-separated list into the clipboard and inserted e.g. into Excel.
 

Microsoft Word reports can be created using the command line tool generate-word-report.bat or generate-word-report.sh.
Locally stored XML reports are processed directly. An export via the client is only necessary once.

The package can be requested via support(at)imbus.de.

The modules (test elements) of the Keyword-Driven Test are locked for all changes from the moment they receive the status "released". However, if data types are used in additional modules or tests, it is often necessary to insert new values in the equivalence classes and data tables, as the existing ones are not sufficient. Up to now, in such cases, the data type was reset to the status "in progress", which then led to the reset of the status "released" of all elements using it.

From now on, additional, new values can also be entered in released data types, i.e. they no longer have to be reset to the status "in progress".
Data and values existing at the time of release can of course still not be changed.

With the modules (test elements) of the Keyword-Driven Test, very complex structures can be modeled in a very compressed way. To see the complexity of a test element at a glance, you can use the static view of the Test Element Browser.

Test elements can now be dragged directly from their position of use within test sequences or parameter lists into the static view. This makes the analysis of existing test definitions a bit easier and faster again.

For each element in the TestBench, it is stored which other elements use or call this element. This makes it easy to determine which elements are affected by changes, for example, or which tests need to be repeated after a change. From this so-called usage list, you can jump directly to the user.

From now on, you can jump directly to the position of use within the using element. For example, for interactions (keywords of the keyword-driven test), the system jumps directly to the test definition and marks the position of the interaction within the test sequence.
This makes jumping between elements noticeably easier and faster. Impact analyses of changes are simplified.

It is now easier to assign errors to test cases:

• Test cases no longer have to be preselected, but errors can be assigned directly to a test case in the list of test cases.
• Errors can be assigned to all test cases simultaneously or removed from all test cases simultaneously.

Within the variant management, changes within a basic test object version (basic TOV) can now be transferred to already derived variants. The transfer is carried out manually from the variant, so that variants can be checked and only updated if there is a real need to update them.

Complete variants, individual sub-trees of the test theme tree or individual tests can be updated.
It is also possible to copy new elements from the basic TOV to a variant. In this cases the derivation for the variant is performed automatically.

The integration of the Robot Framework with the test automation interface of the TestBench was newly implemented.

There are now three plugins available:

1. Robot Framework Export-Plugin
   Serves to prepare the test specification for execution of the automated tests with the Robot Framework.
   The tests can be called directly from the plugin if required.
2. Robot Framework Import-Plugin
   Used to transfer test results from the Robot Framework to the TestBench.
3. Robot Framework Library Import-Plugin
   A large number of libraries exist around the Robot Framework to facilitate the test specification of specific systems or environments. For example there are several libraries around Selenium available. With the help of the plugin, the libraries can be imported into the TestBench, where they are available as test elements in the keyword-driven test. In this way, tests can be specified that can be executed quasi out-of-the-box automatically.

The settings for displaying the diagrams in the Testing Intelligence metric add-on are now saved permanently:

• Grouped or stacked display of bar charts
• Hidden statuses

Hidden statuses can be shown again by simply clicking on the legend.
If these statuses are to become invisible, they can be completely removed from the display.

In the TestBench, the most frequently used mechanism is to mark tests or combine them into sets, that is, the assignment of keywords to tests.
For example, a keyword can mark all tests to be executed automatically every night, which can then be filtered to generate reports or evaluations of the nightly test runs.

This mechanism for filtering by keywords is now also available directly in Testing Intelligence, i.e. the data displayed in the metrics can be subsequently filtered at any time using the keywords set in TestBench.

Testing Intelligence has a new metric that represents the progression of the quality of a system. This is done by relating the test results of the requirements to the number of open errors.

Over time, it is easy to see how the coverage of requirements with tests and the number of errors evolves over time and whether a test end can be reached soon.