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.
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.
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>
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.
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
In project Administration, open Work Items > Custom Fields.
Add a new custom field to the Test Case Work Item type, with ID
Test Steps, and specify the 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.
To enable the Test Records section:
Log in with administrator permissions for the scope you want to configure (repository or project) and enter Administration.
In Navigation, expand Work Items, select Form Configuration, and scroll the page to show the Form Layouts section.
If there is no layout for the Test Case Work Item type, click Configuring Interface Views.and specify the layout as described in the Administrator's Guide topic
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 thebutton on its row in the table.
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" />
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.
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:
Log in to the project with administrator permissions and enter Administration.
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.
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.
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.
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
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
Configure the number of
maxRecentItems to display in the Recent drop-down box.
Enter Administration in the scope you want to configure (Global or project).
In Navigation, expand Work Items and select Form Configuration.
In the Form Layouts section of the page, locate the table row for the Test Case type Work Item, and click .
Locate the following line in the configuration editor:
<extension id="execute-test" label="Execute Test"/>
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.