Setting the Testing Configuration

The Configuration topic (Testing > Configuration) is where you specify how Polarion's Test Case Management feature should work. For field-specific help, please refer to the Quick Help text at the bottom of the Configuration page. This configuration is available in the Global (repository) scope, and in projects. Project settings override the global settings.

The main artifacts of the testing process are:

The Testing Configuration page contains settings that specify a number of properties for Test Runs:

Macros for Test Run Pages

Polarion provides the following macros which can be used to incorporate export-import functionality into Test Run pages:

  1. {export-tests} - Renders a link which launches a dialog enabling a user to export of a set of Test Cases to Microsoft Excel. Use the query to retrieve the test cases to be exported. Example: {export-tests:query=status:active|sortby=id}

    Excel round-trip export prefers the current context's export template when searching for a default one. (It takes first export template in lexicographical order from the project configuration, then the first in lexicographical order from the global configuration.)

  2. {import-test-results} - Renders a link which launches a dialog enabling a user to import a Microsoft Excel file containing test results.

For complete syntax information, see the Syntax Help provided when editing a Test Run page.

Configuring Test Run ID Prefix

You can configure any Test Run Template to add a prefix at the beginning of the IDs of new Test Runs created from the template. The prefix will be added to both manually specified and generated Test Run IDs.

To configure templates to use a Test Run ID prefix:

  1. Review the Test Run Templates, and decide which of them you want to have add a prefix to new Test Run IDs.

  2. In each template you choose, edit the template Properties and enter a prefix value in the Test Run ID Prefix field.

    For example, in a template "Software Design Verification Test", you might specify a prefix like "SWDVT" or "SDV".

When manually creating a Test Run, users can select the Test Run Template. If an ID prefix is configured in the template, and the project is not configured to generate Test Run IDs automatically, the prefix is shown as read-only in the Create Test Run dialog, before the text box in the ID field.

Generating Test Run IDs

You can set up the testing configuration to automatically assign IDs to new Test Runs. When configured, users who manually create new Test Runs do not need to specify an ID, and the naming convention will be consistent for all Test Run IDs.

To enable generated Test Run IDs:

  1. Enter Administration for the project you want to configure.

  2. In Navigation, select Testing > Configuration.

  3. In the Testing Configuration page, check the option Enable Generated Test Run IDs.

Note that this option setting is project-specific. You will need to set it in every project in which you want automatic generation of Test Run IDs.

Generated ID Format

The ID of new Test Runs will begin with the value configured in the Test Run ID Prefix field of the Test Run Template (if one has been specified), followed by a dash (-), followed by a unique ID generated by the system. This ID has the following form:

PREFIX-YYYYMMDD-HHMM with a uniqueness suffix (generated only if necessary) in the form of _NUM

For example: MYPREFIX-20150721-1032 or MYPREFIX-20150721-1032_2 - where MYPREFIX is an ID prefix value that has been configured in the Test Run template (not present if no prefix has been configured), and the trailing 2 in the second example is a uniqueness suffix.

When users manually create a new Test Run, if generated IDs are configured, the ID field is hidden in the Create Test Run dialog. The generated ID appears in the new Test Run after it is created, and the ID cannot be changed.

Limiting Notifications for Imports

The first time you import automated test cases (jUnit tests, for example) to Polarion, it is unlikely that you would want notifications sent about newly created Test Case type Work Items. Also, it is probably not necessary to show all the resulting Create activities in the Activity Stream. This is especially true if you are importing a large number of test cases.

An automated test case is a Work Item of the type configured as Test Case, with a non-empty value in the custom field defined as the Test Case ID (see configuration page in Administration > Testing).

There is a system property that defines a threshold above which notifications are not sent, and the Activity Stream is not updated when new automated test case Work Items are created. The default value is 50, meaning that if more than 50 new Test Case items are created, notifications and activity are not triggered.

If you want to change the default threshold value:

  1. Using any text editor, open the system properties file (follow link for location).

  2. Search for com.polarion.maxNotificationsAboutCreatedTestCases. It is not present in the file by default, so you probably need to add it on a new line.

  3. Set the threshold value as follows: com.polarion.maxNotificationsAboutCreatedTestCases=[VALUE] ...

    ...where [VALUE] is a positive or negative integer, or zero.

    • If [VALUE] is positive, notifications and activity will be suppressed if the number of imported automated tests exceeds [VALUE].

    • If [VALUE] is 0 (zero), no notifications will be sent and no activity will be streamed regardless of the number of automated tests imported.

    • If [VALUE] is negative, no threshold is applied and all notifications are sent and all activity is streamed.


Setting no threshold can result in significant temporary performance degradation of Polarion, your SMTP server, and your network if large numbers of automated tests are imported and no threshold limit is set, to say nothing of user irritation if large numbers of notification emails arrive in their in-boxes as a result of some test case import.

Limiting Test Run Records in History

If you have very large manual Test Runs, the default system configuration can result in excessive numbers of Test Run records in the historical database. In such cases, an administrator can set a system property to reduce the number of records generated. See the Administrator's Guide topic Preventing Excessive Test Run Records for information.