The TestBench Cloud Services provide functionality to support testing in software development projects.
The system hosts many tenants, and for each tenant the users must be logged in separately to get access to their tenants' data.
For this, the users get login credentials from the their Tenant Administrator.
In addition to user login and password, the tenant name is required.
With the link "forgot your password?" a new password can be requested. Therefor the fields Tenant and the User login mus be entered correctly.
An new one time password will be generated and sent to the user.
While waiting to login the loading indicator appears.
The home screen of the system shows the current products under test.
|Element||Right||Test Manager||Test Analyst||Tester|
|Users||To change own password||yes||yes||yes|
|To change own user data||yes||yes||yes|
|Products||To see the list of products with a role in it||yes||yes||yes|
|To delete a product||yes|
|To change the master data of a product||yes|
|To see the user list of a product||yes|
|To change the user list of a product||yes|
|To change the role of a user of a product||yes|
|To see the detailed quality metric of a product||yes|
|To see the list of responsible users for an element||yes||yes||yes|
|To read the product details||yes||yes||yes|
|Epics||To create, to change, to delete an epic||yes||yes|
|To be a responsible user of an epic||yes||yes|
|To read details of an epic||yes||yes|
|User Stories||To create, to change, to delete a user story||yes||yes|
|To be a responsible user of a user story||yes||yes|
|To read details of a user story||yes||yes||yes|
|Test Cases||To create, to change, to delete a test case||yes||yes|
|To be a responsible user of a test case||yes|
|To read details of a test case||yes||yes||yes|
|To insert a test step in a test step block||yes||yes|
|To change a test step||yes||yes|
|To mark a test step block as empty||yes||yes|
|To set or to remove the link of a precondition to a test case||yes||yes|
|To mark the list of precondition as empty||yes||yes|
|To create, to change, to delete a precondition||yes||yes|
|To read the list of preconditions||yes||yes||yes|
|To change name of a precondition||yes||yes|
|To change the status of a precondition||yes||yes||yes|
|Executions||To start an execution||yes||yes|
|To read details of an execution||yes||yes|
|To set the status of an execution||yes||yes|
|To set the execution result of a test step||yes||yes|
|To change the responsible users of an execution||yes||yes|
|Defects||To create, to change, to delete a defect||yes||yes|
|To read the list of defects||yes||yes||yes|
|To link a defect to an execution or to a test step||yes||yes|
|To remove the link of a defect from an execution or from a test step||yes||yes|
In the following all the elements of a product are presented. The
elements are always sorted by their urgency. The most urgent
elements are located in the upper left corner. The less urgent
elements a located in the lower right corner.
The header of the product overview shows the title of the product, the short version of the quality metrics and the button for filtering the elements in the screen and the button to open the products settings.
With the filter the elements shown in the product overview can be
the Button opens the filter:
Product overview filtered by the string "dis".
The filter is closed by clicking the filter icon again. This automatically deactivates the filtering, too. The click on the 'x' button clears the filter string.
An epic is a kind of high level requirement. It describes the functionality of a system on a high abstraction layer and cannot be realized without some kind of decomposition in smaller parts. These smaller parts are the user stories.
Deactivated responsible user.
In order to delete epic, the condition is that epic should not have any User story. If there isn't any user story a confirmation modal will be open, asking `Are you sure you want to delete epic Epic 1`.
Delete epic modal.
Deleted responsible user.
The deactivate or delete user see the User Management chapter.
A user story describes a requirement of a system in a detailed way.The user story can be implemented directly.
Normally user stories are linked to an epic, which collects all user stories of the same topic. But in the product overview a so called free user story can be created, too. The only difference to normal user stories is the non existing link to an epic. Therefore free user stories can be accessed via the product overview. The following descriptions are valid for both variants of user stories, except the linking to an epic.
A user story is created from the epics screen and therefore the user story is linked to an epic. For this the add button in the epic screen is used:
Create a user story.
When a user story is created, the corresponding epic is shown at the left of the screen as a smaller card, so the link to the epic is always displayed.
The click on the epics card opens the epic and displays the user stories linked to the epic as smaller cards.
To open a user story, the card of the user story can be clicked.
The (free) user story has the same fields than an epic and can be edited in the same way (see chapter Epic).
Test Cases are the elements to contain the test specification. At
the moment test cases only supports test cases for manual execution.
Normally test cases are linked to user stories, but in the product overview a so called free test cases can be created, too.The only difference to normal test cases is the non existing link to a user story. Therefore free test cases can be accessed via the product overview and test cases can be accessed via the corresponding user story. The following descriptions are valid for both variants of test cases, except the linking to a user story.
A test case is created from the user stories screen and therefore the test case is linked to a user story. For this the add button in the user stories screen is used in a similar way like in the screen an epic:
Create a test case.
The name, responsible user and the description are used the same way like in epics and user stories. But a test case has some more special sections with special fields.
Each test sequence consists of the six sections Preconditions,
Preparation, Navigation, Perform Test, Check Result and Reset
When a section is fresh and empty the blue question mark is displayed:
A blue question mark signals an empty section.
All the sections are used by the same way (except the Preconditions section):
The list of preconditions is the starting section of the test
sequence. A precondition describes a kind of state, which must be
fulfilled to be ready to test. A typical precondition is the
existence of special test data, which is needed for the execution of
the test case. Preconditions are not only used in a single test
sequence, but they can describe conditions in much more broader
scope. For this, preconditions can be used all over a product.
Preconditions are always created and selected in the precondition sections of test cases.
Precondition section with one entry.
Because of the product wide scope, the precondition must not be
copied when they shall be used more than once. As soon as there are
three characters typed into the field the system displays the list
of matching preconditions. At first the complete matching entries,
then the entries only matching a part of the input.
All preconditions matching the typed in word "the".
The entered preconditions are not only displayed in their test cases, but on the level of user stories and epics, too. The list of preconditions on epic level and user story level contains all preconditions used in the according test cases.
As soon as in minimum one precondition list has got an entry, the blue question mark turns into a red filled circle with a 0% caption. This means a fulfillment degree of the entries in the list of 0%.
No precondition is fulfilled.
Each fulfilled precondition increases this degree. Preconditions can be marked as fulfilled without starting any edit mode or an execution.
For the test cases there is a special view for the test execution,
called execution. A test case is ready for test execution, when the
description is filled and the preconditions of the test case are all
fulfilled (or the section is marked as empty) and all the sections
of the test sequence are filled with at least one test step (or the
section is marked as empty).
When the test case is ready for test the START EXECUTION button appears instead of the DONE button.
The status of a test case is displayed in the top most section of
the test case screen.
Test case with status In Progress.
The status of a test case can be:
||The test case is ready to test.|
||The test execution of the test case is running.
||The result of the last execution is passed.
||The result of the last execution is failed.|
The status is always displayed as a colored pill. These pills are used to summarize the status information on the level of epics and user stories, too.
The number in front of the status is the number of test cases with this status, which belong to the epic or user story.
Each epic and user story have the section Test Cases. In this section the same information is displayed.
Number of test cases and status information of an epic.
Annotation: The total number of test cases (here: 26) must not be the same than the sum of all test cases with a status (here: 25), because there are test cases not ready to test because the test specification is in progress, but only the test execution status is counted.
The Test Execution History lists all performed test runs and the entries in the list are the links to the detailed execution data of each test run.
Three entries in the test execution history.
When a test step is marked as failed or the defect button in the Global defect(s) section is clicked, the screen to create a new defect is opened.
One of the most important elements in the TestBench system are the activities. An activity is work to be done to finish one of the elements inside a product. The activities are displayed in the Open Activities Section of epics, user stories and test cases and in the small cards of epics, user stories and test cases.
||To fill the description.|
|To create at least one user story related to this epic.|
|User Story||To fill the description.|
|To create at least one test case related to this user story.|
|Test Case||To fill the description.|
|To create at least one precondition or
to mark the preconditions section as intentionally left blank.
|To create at least one test step for each section in the
test sequence or
to mark the sections as intentionally left blank.
|To execute the test case.|
|Defect||To close resolved defects.|
||The activity is set less than seven days ago.|
||The activity is set more than six days ago but less than fourteen days ago.|
||The activity is set more than thirteen days ago.|
To know exactly which activities are open, the icons in the activities section can be clicked. This displays the list of activities in order of their severity:
A custom field is a field that is not predefined by the developers of TestBench. It can be defined by the users that have the Tenant Administrator role.
Custom fields can for example be used to define a set of additional information which may be needed in one or more of the elements that can be used in the TestBench. For example epic, user story and all other elements.
If a serial number that must be entered in each of your test cases has to be used there is no need to use, for example the description field, but it is just a matter of adding a custom field, give it a name like "SerialNumber", add a label for that field, may be "Serial Number” and define that this field will be used for all test cases.
After that is done this field can be used in all of your test cases.
A modal dialog opens. Everything that needs to be done to add or
change a custom field or custom field block can be done here.
The modal contains three different tabs:
With the trash can one or more custom fields can be deleted,
multiple selection of the fields is possible.
Below the head line there is a table, which shows a list of all
already defined custom fields. This list can be sorted by Name,
Label, Type and Block Assignment.
The right part of the window is dedicated to give access to the details of one single custom field that is selected on the left side. It is also used to enter all new values needed if a new custom field is added.
||Defines the name that this custom field has internally in
||Defines the label, which is used when this custom field is
displayed. After creating a custom field per default the label
gets the same value like the name.
||A default value for the field can be added. This default
value is always displayed as long as the field contents is not
|Custom Field Type
||The Custom Field Type is used to define the type of the
custom field. Available types are: SingleLineText,
ATTENTION: Changing the type subsequently, ALL saved values will be lost in any element as soon as you have selected and changed the type.
||Block Assignment is used to place the custom field in one or
more custom field blocks. Available custom field blocks are
defined in the CUSTOM FIELD BLOCKS tab.
The block assignments of the selected custom field can be removed, by clicking the red round button on the right of the custom field block name. A dialog appears that asks if the user is sure that he wants to remove the assigned custom field block.
Current custom field limitations are:
|Type||Maximum text length||Line breaks allowed||Trimmed|
||255 printable characters||No||No|
|MultiLineText||65 535 characters||Yes||No|
An empty single line text field in display mode.
A single line text field in edit mode could be filled with 255 printable characters.
A multi line text field in edit mode. The field can be filled with multiple lines until the field limit has been reached.
Link fields are a little bit different from other fields,
especially from single line text and multi line text fields.
They should contain a link like "protocol://path". At the left side of the link field, there is an icon. Via click on a green icon the entered link opens in a new tab. Just clicking on the link itself inside the field will not result in opening this link, but in starting the edit mode.
Note that file links like "file://path" are blocked by most browsers.
The icon is displayed in green if a link field is filled. Be aware that this view is not a check for validity or availability of the link.
A link field in edit mode. In this mode the icon is grey.
All custom fields could be filled with data by clicking on the green edit icon or into the grey area. Both will be shown if the mouse hovers over the field.
In edit mode the data will be saved by clicking the hook icon. To discard the last input the "x" icon must be clicked.
As long as a custom field is empty "Add 'Label of the field' " is always displayed instead of the content.
Below the head line there is a table, which shows a list of all
already defined custom field blocks. This list can be sorted by Name
and Product Assignment.
Product assignment column displays the products in which the custom field block is assigned.
||Defines the name that this custom field block has internally
in the application.
||Defines the product assignment of the selected custom field
block, which by default is 'All Products'. The product
assignment of a custom field block can be changed by selecting
the wanted product in the list of available products, which
appears by clicking on 'Assign products'.
|Custom Field Assignment
||Custom Field Assignment is used to assign custom fields to
the selected custom field block. Available custom fields are
defined in the CUSTOM FIELDS tab.
Removing a custom field assignment from the selected custom field block can be done by clicking the red round button on the right side of the row, which opens a dialog that asks if the user is sure that this assigned custom field wants to removed.
An other possibility is changing the custom fields order in the selected custom field block, and this is done by drag and dropping the custom field inside the custom field assignment table, by the icon of two horizontal lines on the right side of the row.
|Before Test Cases|
|User Story||Before Description|
|Before Test Cases|
|Test Case||Before Description|
|Before Execution History|
|Before Test Sequence|
|Test Execution||Before Description|
|Before Execution History|
As previously explained custom fields can be used in all elements
that are at hand for the user of TestBench.
The custom fields are displayed in all elements where the user assigned them.
The order of the custom field blocks in a container and the custom fields inside a block appear exactly like the user defined them in Custom Field Management
Here a sample for a test case:
the TestBench application there is one place where the user will
see two different custom field parts. Whenever a new test
execution is created, the custom fields for that test execution
will be available. As the application saves the values of
different fields from the test case which is the source for that
test execution, the application saves the labels and values for
the custom fields defined for that test case.
All those so called frozen fields will be shown in the last section of that execution named "<block name> (specification)" and they are not changeable regarding custom field type, label or content.
Each half star of an individual goal counts 10% and each full star counts 20%. With clicking on the stars the stars can be set or reset.
When selecting one or more user, in the Users table header two
When a deactivated user is selected the deactivation icon toggles to the activation icon and the user can be activated:
In the same we way can activate the deactivated user.
Multiple users can be activated/deactivated at the same time, as long as all the selected users are activated or deactivated.
A deactivated user cannot login to the tenant and cannot be assigned as responsible person.
The TestBench system allows to import epics and user stories from Jira to your product in TestBench. The imported requirements are read-only in TestBench, and Jira is the master of the data.
During a synchronization with Jira, existing requirements are updated, and new requirements are added in TestBench. Although the imported epics and user stories are read-only, they can be linked to user stories and test cases created in TestBench. Imports do not affect these user stories or test cases created in TestBench. That way, you can connect all test cases with the proper epics and user stories of your Jira project.
To import the epics and user stories from your Jira system to TestBench, the Jira Url (HTTPS only) and a valid login and password is required. The Jira Server Certificate field can be left empty in most cases. It is needed only if connecting to a self-hosted Jira server that uses a self-signed HTTPS certificate - in this case, enter here the Base64 encoded PEM format certificate (i.e., a certificate text starting with "-----BEGIN CERTIFICATE-----" and ending with "-----END CERTIFICATE-----").
The epic configuration and user story configuration allows to specify the JQLs that control which issues will be imported as epics and as user stories. Note that the JQLs should not contain any "ORDER BY" clauses, because TestBench internally adds an "ORDER BY created ASC" clause to ensure optimum import results. During the configuration of the JIRA connection and the JQL settings, TestBench provides feedback of how many elements the synchronization will import into TestBench.
"SYNCHRONIZE NOW" starts the import of epics and user stories from Jira into TestBench. Note that if issues are moved or deleted in JIRA while a synchronization is running, in TestBench some of the imported requirements may not show the expected status. This inconsistency will mend automatically with the next synchronization.
Requirements can be imported from Atlassian Jira Cloud instances. The connection from user stories to the corresponding epics is determined by reading the Jira custom field named "Epic Link" in user stories.
Requirements can also be imported from a self-hosted Jira server, provided a recent version of Jira Software Server is installed and the Jira server is reachable from the TestBench CS server via HTTPS. The connection from user stories to the corresponding epics is determined by reading the Jira custom field named "Epic Link" in user stories.