Configuring Manual Test Steps

For manual testing, it is possible for testers to track not only the overall results of a Test Case (passed/failed), but also the results of each test step in a Test Case.

Figure 6.7. Test Case with Manual Test Steps

Test Case with Manual Test Steps

Users can log results of individual test steps

There is a special Work Item field Test Steps, to be used in Test Case type Work Items. It is rendered as a table, with each row representing a discrete manual test step. Columns of the table are user-configurable. You may need to enable test steps in your project configuration if the feature is not already enabled by the project template. This section discusses these configurations.

When correctly configured, a table of test steps appears in the Custom Fields section of new Test Case items in which testers can specify each test step (unless an administrator has configured the field to appear separately on the Work Item detail form). This table is rendered as executable test steps in a panel below the Test Run's table of Test Cases. (It has an Execute Test Case heading when Classic execution view is enabled.

TIPS

  • Some project templates delivered with some products may have steps already configured. You can tell by creating a new Test Case in the tracker and checking whether a Test Steps table is present. (You can then cancel the Create Test Case operation without saving.) Even if Test Steps are pre-configured, you may still want to customize the Test Steps table as mentioned in step 4 above.

  • You can optionally display Test Steps as a separate field in Test Case items, rather than in the Custom Fields section. To do this, you must edit the form layout for the Test Case type (Administration > Work Items > Form Configuration). If no Form Layout exists for the Test Case type, you can create one. (See Administrator's Guide topic Configuring Work Item Form Layout).

    In the layout configuration, add the Test Steps field (for example: <field id="testSteps"/>), and remove the Test Steps field from the configured custom fields to be displayed:

    <panel description="Custom Fields">
        <field id="@allCustomFields,-testType,-testSteps"/> 
    </panel>
                            

Migrating Existing Test Steps Data

In earlier implementations of the Test Steps feature, manual test steps were created and stored in the Description field of Test Case type Work Items. In later implementations test steps are created and stored in the dedicated Test Steps field described above. If you have projects in which test steps data are still stored in Description fields, an administrator can migrate the existing data to the Test Steps field.

Polarion provides a special migration guide document, which explains how to perform this migration. The guide is available on the Polarion ALM product web site at https://www.polarion.com/hubfs/Docs/Guides_and_Manuals/Polarion-Test-Steps-Migration-Guide.pdf.

Enabling Test Steps Support

You can enable the Test Steps feature either globally or per project. You can also add this configuration to any existing custom project templates that for projects that include testing support. This process step requires editing XML configuration code.

To configure a custom field for Test Steps

  1. In project Administration, open Work Items > Custom Fields.

    Add a new custom field to the Test Case Work Item type, with ID testSteps, name Test Steps, and specify the Test Steps type. The custom field type "Test Steps" renders a table of test steps in new Test Case items. Note that you can add only one custom field of this type to the configuration.

Enable the Test Records Section

To enable the Test Records section:

  1. Log in with administrator permissions for the scope you want to configure (repository or project) and enter Administration.

  2. In Navigation, expand Work Items, select Form Configuration, and scroll the page to show the Form Layouts section.

  3. If there is no layout for the Test Case Work Item type, click Create New Form Layout and specify the layout as described in the Administrator's Guide topic Configuring Interface Views.

    If the table of layouts does contain a layout for the Test Case type (or whatever custom type of yours corresponds to a test case), click the Edit button on its row in the table.

  4. If the following element is not already present, add it below the execute-test extension element:

    <extension counts="1,5,10" id="test-records" label="Test Records" />

  5. Save the configuration. Note that you need to repeat this configuration in every Interface View that has a form layout for Test Cases, and in which you want the Test Steps feature enabled for Test Cases.

For Projects created prior to Polarion 12.3

Contact Technical Support (GTAC), if you have projects created prior to Polarion 12.3 that you want to Execute a Test Run Using Polarion for.

Configuring Test Step Columns

The table of the Test Steps field contains some columns controlled by Polarion (Actual Result, for example) and some columns that you can modify. The user-modifiable columns (only) are accessible in a dedicated Administration page. There, you can customize the table, adding additional columns, and adjusting headings of the user-modifiable columns to use your own semantics.

To access the Test Steps Columns configuration:

  1. Log in to the project with administrator permissions and enter Administration.

  2. In Navigation, expand Testing and select Test Steps.

Refer to the embedded Quick Help text on the configuration page for information about how to perform the configuration.

TIP

If your users write up test case specifications in LiveDoc documents, it will be necessary for them to set the Document's Work Item Presentation to show the Test Steps field in Document-based Work Items. For more information, see the User Guide topic Editing Test Steps in Documents.

Controlling Time Tracking for Test Execution

By default, Polarion tracks time expended on executing manual tests and includes it in Test Records, which are visible to all users with the necessary view permissions. There are some jurisdictions that prohibit the visibility of tracking of individuals' time. If you need to stop the tracking and display of time spent executing manual tests in order to comply with local laws, there is a special system property you can use: com.polarion.alm.ui.forms.extensions.disableTimeSpentRecording . If set to "true", then time spent during manual test execution is not stored within test records. (Automated test results import still imports the duration of tests.)

To disable time tracking of manual tests, add the system property disableTimeSpentRecording to the system configuration file polarion.properties (follow link if you need the location). Set the property to the value to "true", and restart the Polarion server after the change.

Example: com.polarion.alm.ui.forms.extensions.disableTimeSpentRecording=true

Displaying Recent Results

Only with Classic Execution View

The Recent drop-down list described in this section is currently only available in the Classic Test Execution View.

By default, each Test Step displays the Recent drop-down, which lists the Actual Result values from the most recent execution of the step during a Test Run. The Test Case Verdict field displays a similar drop-down with the values of the most recent verdicts. Users can select one of the listed previous results as the result of the current step execution or current Test Case verdict.

You can control how many recent values are displayed in these drop-down lists, or hide the lists completely (not recommended) using the maxRecentItems option in the Test Steps extension element of the Work Item form layout configuration for Test Case type Work Items.

Configuring the number of Recent Test Records Polarion should analyze:

Administrators can define the maximum number of test records to analyze by adding the following property in the polarion.properties file:

com.polarion.alm.ui.forms.extensions.testExtensionRecordsLimit = 20

(The default value is 20)

Polarion starts with the testExtensionRecordsLimit value, eliminates any duplicates or empty results, then displays the maximum number of results defined in the maxRecentItems property.

Configure the number of maxRecentItems to display in the Recent drop-down box.

  1. Enter Administration in the scope you want to configure (Global or project).

  2. In Navigation, expand Work Items and select Form Configuration.

  3. In the Form Layouts section of the page, locate the table row for the Test Case type Work Item, and click Edit.

  4. Locate the following line in the configuration editor:

    <extension id="execute-test" label="Execute Test"/>

  5. Add the maxRecentItems option to the line, specifying the maximum number of unique recent items to display to use in the drop-down lists, or 0 (zero) to hide the lists. For example:

    <extension id="execute-test" label="Execute Test" maxRecentItems="10" />

Note that some project configurations may contain several different types of test cases: System Test Case, Software Test Case, Mechanical Test Case, etc. You will need to perform the above configuration for each of the test case types, assuming the form layout contains the extension element enabling manual Test Steps.