Online help TestBench Cloud Services

Online Help

TestBench Cloud Services, Version: 1.2

The TestBench Cloud Services provide functionality to support testing in software development projects.

Login

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.


login screen
Login screen.


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.

Reset password.
Reset password.

An new one time password will be generated and sent to the user.


login loading indicator

While waiting to login the loading indicator appears.

Home Screen


The home screen of the system shows the current products under test.


The home screen lists all products under test.
Home screen with two products.

A product is the container of all epics, (free) user stories, (free) test cases, test executions and defects are needed to evaluate the quality of the product.

Each product is listed with many additional information:
  • Nearby the name of the product the short view of the quality metric of the product is displayed. A click on it leads to the detailed metric.
  • The six most urgent elements are listed in the sequence of their urgency.
  • A little statistic which lists all elements with their activities urgency.

  • A click on the title of a product opens the product screen. A click on one of the elements listed, is a link to this element and opens this element directly.

    Product

    The add button creates a new and empty product. Only Tenant Administrators have the rights to do this.
    New products are created with the add button.
    Add button.

    To add a new product the name of the product must be entered.
    Add a new product with the name "My new product".

    Only a tenant administrator has the privileges to create, administer and configure a product.
    After creating a new product the product has only a name.

    new, but empty product
    New, but empty product.

    Only the Tenant Administrator creating the product has privileges to work within the product.
    Therefore some settings should be done. The settings of the product can be opened via the settings icon.

    settings icon
    Settings icon.

    At first the product should get a more detailed description. The description is set in the product's MASTER DATA.

    product description
    The description is set in the MASTER DATA.

    The PRODUCT QUALITY is described in the Product Quality chapter.

    The next more important data to be set are the users, who shall have access to the product.
    The users must be created by a tenant administrator before they can be assigned to a product (see chapter User Management).
    This users are assigned and configured in the product's USERS section.

    users section of the product
    The USERS section.

    With Add user an existing user can be assigned to the product. The shown users list to select an entry is reduced to the matching entries when there are some characters typed in.

    select an user from the list
    Assign a user to the product.

    The assigned users are listed in the users list of the product. There they get the intended rights.


    added user in the users list
    The user is added to the list.


    Inside a product a user can get the roles Test Manager, Test Analyst and Tester with the according rights:

    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
    Table of user rights by user role.


    user gets the test manager role
    The user gets the test manager role.


    The user gets full access when all the roles are set.
    When the user gets all three roles he/she gets full access.

    Product Overview


    In the product overview all the elements of a product are listed.

    The product overview lists all elements of the product.
    Product overview.

    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 filtered.
    the Button opens the filter:


    Open filter
    Open filter.

    With each character typed into the filter field, the name of the elements in the product overview are searched for matches. The contents is adapted immediately. The filter shows how many entries are found over all entries.
    The filter value will also be mirrored in the browser url, so it can be stored as a bookmark for later use. If a url with a filter is opened, the view will show only the matching elements.


    filtered contend of the product overview

    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.


    Epics


    Inside the product overview, with the add button new epics, free user stories (user stories without a link to an epic, see User Stories chapter)  and free test cases (test case without a link to a user story, see Test Cases chapter) can be created.

    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.


    Add epic, free user story or free test case
    Add epic, free user story or free test case.


    Add new epic
    Add a new epic.


    Right after adding a new epic the so called global edit mode of the epic starts. This means all fields of the epic are in edit mode.
    By default, the focus is set into the description field.

    New epic in global edit mode
    The new epic in global edit mode.

    Now all the fields can be accessed and changed easily. The change of each field must be confirmed separately. With this confirmation the data of the field is committed at once.
    With the DONE button the global edit mode is closed. The global edit mode can be started again with the edit button:

    Edit button to start the global edit mode
    Edit button to start the global edit mode.

    In addition to the global edit mode there is a so called quick edit mode for each field. The quick edit mode changes always one field.

    quick edit mode
    Quick edit mode of the description field.

    To activate the quick edit mode for a field, the small edit button at the right top of the hover area of the field must be clicked. Additionally it also works to click on the gray area. A text can be selected without entering the quick edit mode. If a text is already selected, a click on the gray area will deselect the selected text. The click on the quick edit button always will enter the quick edit mode, even if a text is already selected.

    Each epic can get several responsible users. When responsible users shall be added, a list of all user of the product who have the correct rights is displayed to select a user. In the list, the name and the roles of the user is shown.

    add responsible user
    Add a responsible user from the users list.

    A responsible user is added
    A responsible user is added.

    To remove a responsible user the edit mode of the field must be started, too. Clicking on the minus symbol nearby a users name removes the entry from the list.

    Deactivated users will be shown in light grey color, but cannot assigned as responsible user anymore.
    Deleted users are deleted from the users list but an entry "Deleted user" will be displayed instead to show that there were one or more deleted users in the list.
    When editing a users list with deactivated or deleted users, this users will be removed from the list when starting the edit mode.

    deactivated responsible user
    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`.


    open delete epic

    Delete epic modal.


    deleted responsible user
    Deleted responsible user.


    The deactivate or delete user see the User Management chapter.


    The Open Activities section is described in the Activities chapter.

    The Test Cases section is described in the Test Cases Chapter and the Test Status chapter.

    The list of preconditions is described in the Preconditions chapter.

    User Stories


    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 an user story out of the epic screen.

    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.

    New epic with corresponding epic.
    New user story with the corresponding epic.

    The click on the epics card opens the epic and displays the user stories linked to the epic as smaller cards.

    Epic with user story.
    Epic with linked user story.

    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


    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.

    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.


    Screen of my first test case.
    A test case right after creation.

    Like a user story, the test cases are linked to their parent element. In the screen the whole trace form the corresponding epic and the user story is displayed.

    Trace form epic to test case.
    The trace from epic to test case is always displayed.

    Test Sequence

    Each test sequence consists of the six sections Preconditions, Preparation, Navigation, Perform Test, Check Result and Reset Environment.

    When a section is fresh and empty the blue question mark is displayed: 

    Blue question mark signals an empty section.
    A blue question mark signals an empty section.

    All the sections are used by the same way (except the Preconditions section):


    A section can be edited separately via their quick edit mode or via the global edit mode of the test case.

    Quick edit mode hover of preparation section.
    Quick edit mode hover of the preparation section.

    Initiated edit mode of the preparation section.
    Initiated edit mode.

    As long as there exists no test step in a section, the Leave blank option can be used. When this option is activated, the section is evaluated as intentionally left empty but completed.

    Preparation section intentionally left blank.
    Preparation section intentionally left blank.

    A test step can be added via clicking on the plus button or by clicking in the field directly.
    First test step added to section preparation.
    First test step added.

    Test steps can be deleted by the red minus button and can be moved via drag and drop by the double line button.

    First test step added to section preparation.
    First test step added.

    When a section has got one test step in minimum or is intentionally left blank, the blue question mark of the section turns into a white ring.
    During the test execution, each test step can be set as passed or failed and can get links to defects.

    Example of a test sequence.
    Example of a test sequence.

    The intentions behind the different sections are:

    Preparation: Used to do some preparation before the test can be executed. Typical preparations are loading special data into the system under test or set some options needed.

    Navigation: By these steps, the tester is typically directed through the system under test to reach the location or the state, the test needs to start.

    Perform Test: These are test steps, which stimulates the system under test, e.g. by inputting some data or changing the state of a functionality.

    Check Result: These steps hold the expected results. When are all the expected results are fulfilled, normally the test case is passed.

    Reset Environment: After the execution of a test case, sometimes some cleanup is needed to get a proper environment for the next test cases.

    Preconditions

    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.
    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.
    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%.

    Fulfillment degree of zero for the preconditions.
    No precondition is fulfilled.


    Each fulfilled precondition increases this degree. Preconditions can be marked as fulfilled without starting any edit mode or an execution.

    One of four preconditions is fulfilled.
    One of four preconditions is fulfilled.

    Two of four preconditions are fulfilled.
    Two of four preconditions are fulfilled.

    All four preconditions are fulfilled.
    All four preconditions are fulfilled.

    The preconditions can be marked as fulfilled in the lists of all three levels. The marking of a precondition as immediately populated to all other elements, the precondition is listed.

    Executions

    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.

    When the test case is ready for test the START EXECUTION button appears.
    START EXECUTION button.

    But the execution can be called from the three dot menu at any time, too.

    Menu of the test case.
    Menu of the test case.

    When the test execution is started, the test case is displayed in the execution view.

    Execution view of a test case.
    Execution view of a test case.

    In the execution, responsible users with the role tester can be added.
    The test result status can be set, but by default this status is evaluated automatically from the test results of the test steps of the test sequence. When there are no test steps, the status mus be set manually. When the status is set manually, a little wrench is displayed near by the status.

    The preconditions show their fulfillment status, but cannot be change (e.g. this can be done from the test case view).

    Each test step can be marked as passed via the circle with the hook, and marked as failed via the circle with the bug inside.

    Test steps marked as passed or failed.
    Test steps marked as passed or failed.

    The test step status can be toogled by multiple clicking these buttons.

    When a test step is marked as failed the defect screen appears to create a defect to document the failure. A defect can be created at any time by clicking the circle with the number nearby the failed button. F or details see the chapter Defects.

    In the execution view there are two more sections:
    In the Global defect(s) section, the user can create defects which cannot assigned to a single test step but relates to the whole test case.
    Another section displays the parts of the test sequence like a pearl necklace to give a fast overview of the status of the test sequence.

    Short overview of the test sequence status.
    Short overview of the test sequence status.

    For each section of the test sequence the passed or failed status is displayed. The first section with a test step with no status is marked with a traffic cone. The last row with the numbers displays how many preconditions or test steps are in the according section.  

    With the STOP EXECUTION button, the execution of the test case is stopped, but not aborted. The execution can continued with the help of the Test Execution History.

    Menu of test execution.
    Menu of test execution.

    With the menu entry START NEW EXECUTION the current execution is stopped and an additional new execution is started.


    Test Status

    The status of a test case is displayed in the top most section of the test case screen.

    Test case with status In Progress.
    Test case with status In Progress.

    The status of a test case can be:


    Status Description
    Ready
    The test case is ready to test.
    In Progress
    The test execution of the test case is running.
    Passed
    The result of the last execution is passed.
    Failed
    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.


    A user story card with all the four status pills.
    A user story card with all the four status pills.


    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.
    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.

    Test Execution History

    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.
    Three entries in the test execution history.


    Each entry in the history shows for this execution the date, the user who has performed it, the status and the number of defects linked to this execution. The latest execution is listed as first entry and this latest execution determines the current result of the execution.

    With a click on an entry in the list, the according execution is opened and the user can change any data in the execution.

    Defects

    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.


    Add a new defect.
    Add a new defect.

    In the screen to create a new defect at first the title of the defect must be entered. The description of the test step is displayed, too.
    When the title is saved, the next screen opens automatically to enter the other fields of the defect.

    Enter detailed defect data.
    Enter detailed defect data.

    In addition to the name and description, responsible users can be added and the status, priority and severity of the defect can be set.

    Different defect status.
    Different defect status.

    The starting status is NEW. In the quality metric of the product, the status CLOSED regards the according defect as done.

    The priority can be set to Low, Medium and High. The default priority is Medium.

    The severity can be set to Minor, Moderate, Major and Critical. The default is Moderate.

    Activities

    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.


    Three open activities.
    Three open activities for this element.

    Activities are set automatically for epics, user stories, test cases and defects.

    Element Activity
    Epic
    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.

    Table of the activities.

    When an activity is done the according activities counter is decreased automatically. When the counter is set to zero the activities icon is not displayed.

    To indicate the urgency of an activity, there are three severities each activity can get.

    Severity Description
    Info
    The activity is set less than seven days ago.
    Flash
    The activity is set more than six days ago but less than fourteen days ago.
    Flame
    The activity is set more than thirteen days ago.

    Table of activity severities.

    The three states are marked with icons and colors.

    Open activities in all the three states.
    Open activities in all the three severities.

    For the state Flame the small card of the according element is filled with red color.

    Small card of a flamed epic.
    Small card of a flamed epic.

    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:


    list of open activities
    List of open activities of an epic.

    In the list each entry shows the missing activity in the first line and the icon and name of the affected element.

    When the current element is affected, the second line is not displayed:

    activities list of the current element
    List of activities of the displayed user story.

    A click on an entry of the list jumps to the affected element.

    Custom Fields

    A very flexible and important element in TestBench system is the ability to define and use custom fields.


    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.


    Configuring Custom Fields

    The first thing is to open the dialog where custom fields can be managed. The navigation can be found here if the user has the role of a Tenant Administrator


    This is where navigation to custom field management happens
    Menu entry to the custom field
    management for tenant administrators.

    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:

    1. CUSTOM FIELDS
    2. CUSTOM FIELD BLOCKS
    3. CUSTOM FIELD BLOCK ASSIGNMENT


    Custom Field Management.

    CUSTOM FIELDS

    The custom fields window is split in two parts.
    The left part gives an overview about the custom fields already defined and to enable the user to add a new custom field. It is also used to select custom fields that need to be modified

    On top of the left part of the window there is a head line. In this head line the user is able to add a new custom field.

    click this button to add another custom field

    active add another custom field entry point

    With the trash can one or more custom fields can be deleted, multiple selection of the fields is possible.


    delete the selected custom field

    ATTENTION: Only unassigned custom fields can be deleted

    By clicking the trash can icon a dialog opens that informs the user which of the selected custom fields can be deleted.

    delete the selected custom field dialog

    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.


    list of all custom fields


    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.


    custom field right column


    Name
    Defines the name that this custom field has internally in the application.
    Label
    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.
    Default Value
    A default value for the field can be added. This default value is always displayed as long as the field contents is not changed.
    Custom Field Type
    The Custom Field Type is used to define the type of the custom field. Available types are: SingleLineText, MultiLineText, Link

    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
    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.

    Add block assignment for a selected custom field

    Remove block assignment for a selected custom field

    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.

    delete block assignment of custom field

    remove assigned custom field block




    Current custom field limitations are:

    Type Maximum text length Line breaks allowed Trimmed
    SingleLineText
    255 printable characters No No
    MultiLineText 65 535 characters Yes No
    Link 2000 characters No No

    SingleLineText

    single line custom field in show mode

    An empty single line text field in display mode.


    single line custom field in edit mode
    A single line text field in edit mode could be filled with 255 printable characters.

    MultiLineText
    multi line custom field in show mode
    A filled multi line text field in display mode.



    multi line custom field in edit mode

    A multi line text field in edit mode. The field can be filled with multiple lines until the field limit has been reached.

    Link

    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.


    link custom field in show mode
    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.


    link custom field in edit mode
    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.


    CUSTOM FIELD BLOCKS

    The custom field block window is split in two parts.
    The left part gives an overview about the custom field blocks already defined and enables the user to add a new custom field block. It is also used to select custom fields blocks that need to be modified.

    On top of the left part of the window there is a head line identical like in the Custom Field tab. It allows the user to add a new custom field block.

    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.


    list of all custom field blocks


    The right part of the window is dedicated to give access to the details of one single custom field block that is selected on the left side. It is also used to enter all new values needed if a new custom field block is added.

    right column of custom field blocks tab

    Name
    Defines the name that this custom field block has internally in the application.
    Product Assignment
    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 block product assignment

    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.

    Add block assignment for a selected custom field

    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.

    remove assigned custom field

    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. drag and drop custom field assignment


    CUSTOM FIELD BLOCK ASSIGNMENT

    The custom field block assignment contains the available containers of the application. Each container has predefined anchors.

    Container Anchors
    Epic
    Before Description

    Before Activities

    Before Test Cases
    User Story Before Description

    Before Activities

    Before Test Cases
    Test Case Before Description

    Before Activities

    Before Execution History

    Before Test Sequence
    Test Execution Before Description

    Before Execution History
    Defect Before Description

    Bottom



    custom field block assignment container


    On the anchors of one container the user can assign the available custom field blocks.
    custom field block assignment anchor

    ATTENTION:
    1. The same custom field block can not be assigned twice in an anchor.
    2. If an anchor has already assigned custom field blocks, the user can not assign new custom field blocks that contain custom fields that are already assigned to other custom field blocks in that anchor.


    The order of the custom field blocks inside a anchor can change by drag and dropping the custom field block, using the two horizontal line icon on the right corner of the custom field block row. The drag and drop option can be used to move the custom field block from an anchor to another and from a container to another.



    ATTENTION:
    A custom field block can not be moved from a container to another if the other container already contains that block in one
    of its anchors.

    drag and drop custom field block in container
    A custom field block can be unassigned from a anchor, respectively one container, by clicking the red round button on the right corner of the custom field block row, which opens a dialog that asks if the user is sure about removing the assigned custom field block.

    remove assigned custom field block from container

    Usage of Custom Fields

    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:

    test case custom field blocks

    In 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.

    test execution sample



    Progress Indicator

    Another mechanism to display the progress of an element is the progress indicator. Each epic, user story and test case have a special progress bar at the left side of their view or small card.

    Progress indicator of a test case.
    Progress indicator of the small card of a test case.

    The indicator has two bars:
    • The left one indicates the progress of the test specification.
    • The right one indicates the degree of fulfillment of the preconditions.

    For the epics and the user stories the indicator displays sum of the progress of all according sub elements.

    By default the system assumes that 100% test specification progress can be reached with at least five sub elements. This means that a user story must have at least five test cases with 100% test specification progress to reach the 100% test specification progress for the user story. The same goes for an epic.

    For test cases the progress indicator changes its behavior when the test case has one of the status Ready, Passed or Failed. In this cases the indicator has a single bar filled with the color of the according status pill.

    Indicator for status Passed of a test case.
    Indicator for status Passed of a test case.


    Epic with its user stories and progress indicators, activities and execution status.
    Epic with its user stories and progress indicators, activities and execution status.

    The small cards of the user stories are listed in the sequence of their urgency. The most urgent user stories are listed at the top.

    Product Quality

    The progress of the quality of a product is measured with the help of the quality metric. The metric is displayed in the QUALITY METRIC section inside the settings of a product.

    As specific goal to be reached quality goals can be set. The Overall Quality Goal is evaluated from several Individual goals.

    List of quality goals of a product.
    List of quality goals of a product.

    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.
    Annotation: To reach a full star, the click must be located in the upper right corner of the star.

    The average of all individual goals is set as Overall Quality Goal. In the example above the overall quality goal is 83%.

    Detailed quality metric of a product.
    Detailed quality metric of a product.

    At the left side of the metric the Overall Quality Goal is marked with a flagged green line. The current degree of quality is displayed with a thick green line.
    At the right side the open defects are counted and the highest number and the current number of defects are displayed. The current number is only displayed when this number is lower than the highest number. The shown period of the graph is 31 days back.

    A mouse over effect displays for each day the detailed data.

    The quality goal is increased by executions of test cases with the result Passed.

    The goals are to reach the Overall Quality Goal and to decrease the number of open defects. A defect must be set to the status CLOSED to decrease the number of open defects.

    A smaller and shorter version of the quality metrics is displayed in the product title.

    Small quality metric.
    Small quality metric.

    The small metric only displays the last seven days and has no mouse over effects. With a click on the small metric, the detailed metric is opened.

    User Management

    The tenant administrators must create accounts to grant access to other users.

    Menu entry to the user management for tenant administrators.
    Menu entry to the user management for tenant administrators.


    User list of a tenant.
    User list of a tenant.

    With the help of the ADD button a new user can be created.

    The data of a new user is entered.
    The data of a new user is entered.

    When a new user is created the tenant administrator assigns a one time password to the user and the user can only get access when she or he set a new password during her/his first login.
    A confirmation email is sent to the entered email address. As long as the user does not confirm the email address with the help of the included link, the user get no access to the system and in the detailed data of the user the email address is marked as pending. The confirmation must be done after 48 hours.

    Detailed data of a new user with an unconfirmed email address.
    Detailed data of a new user with a unconfirmed email address.

    In the users detailed view the users data can be changed by tenant administrators.
    When the email address is changed a security warning email is sent to the old email address and a confirmation email to the new email address.

    To change the password during next login can be forced by the according switch.

    In the same way the user can get rights inside of the product settings the rights can be granted in the user management.

    When selecting one or more user, in the Users table header two icons appear:

  • deactivate the selected user entries: deactivate user
  • delete the selected user entries: delete user

  • When a deactivated user is selected the deactivation icon toggles to the activation icon and the user can be activated: activate user


    Deactivate the user Chuck Norris

    In the same we way can activate the deactivated user.


    Activate the user Chuck Norris

    Multiple users can be activated/deactivated at the same time, as long as all the selected users are activated or deactivated.


    Activate/Deactivate multiple users at the same time

    A deactivated user cannot login to the tenant and cannot be assigned as responsible person.


    Each user can set her/his own data by the user settings found as menu entry over her/his login name.

    Settings of the user Chuck Norris.
    Settings of the user Chuck Norris.

    When the user changes her/his own email address a security warning email is sent to the old email address and a confirmation email to the new email address.The change of the password must be authorized by the old password.

    Settings for changing password


    After switching to password view, there are three required fields. First one is old password (which will be validated if its correct only after clicking CHANGE PASSWORD button), and the two other fields are new password and confirm new password (which will be valiadated while user is typing).

    Requirements System

    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.


    Settings for connecting to Jira

    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.


    System Requirements for importing requirements from Jira

    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.

    System Requirements

    The TestBench user interface is tested for several browsers but it is impossible to optimize the code of the interface for all existing browsers. Therefore, the system can only be accessed by a limited number of browsers.

    Fully supported browsers:

    Google Chrome 66.0 and newer versions (recommended browser)
    Mozilla Firefox 60.0 and newer versions
    Mozilla Firefox ESR 60.0 and newer versions
    Opera 54.0 and newer versions

    Limited supported browsers:

    Google Chrome 55.0 and newer versions lower than 66.0
    Mozilla Firefox 52.0 and newer versions lower than 60.0
    Mozilla Firefox ESR 52.0
    Apple Safari 11.0.3
    Opera 51.0
    Microsoft Edge 15.15063 and newer versions
    Microsoft Internet Explorer 11.0

    When a limited supported browser is used the system alerts this and grants access only by clicking an ENTER AT YOU OWN RISK confirmation button. For this browsers the vendor does not guarantee a bug free user experience. It is strongly recommended to use one of the fully supported browsers.

    For all other browsers the access to the system is blocked and there is no guarantee that this browser will run the system in any way.

    To use the system it is required that the local storage of the browser must be accessible and that JavaScript must be switched on.
    When one of these requirements are not fulfilled the system denies the access.

    The WSS-Protocol needs to be enabled within the TestBench users network.

    For any questions, please send an email to support@testbench.com.