Classic test execution view

You can switch back to the classic execution view method described below by entering the following property in the Configuration Properties section in Administration.

testManagement.useOldExecutionView=true 
Warning:

To give current testers some time to transition to the new Test Execution View workflow, we will still support the Classic Test Execution View for a few more releases.

Recommendation: Get to know the improved workflow outlined in the Executing a Test Run Using Polarion section.

Execute a manual Test Run with the classic Test Execution View

  1. Open the Test Run's page by clicking on the Test Runs in Navigation, and selecting the Test Run in the table of Test Runs. If there are many Test Runs, you can use the visual query builder on the Test Runs page to build a query to filter the table. For example, you might query for only Manual type tests, based on a specific Test Run Template.

  2. Click Execute Test. The Work Items table opens in a new browser tab with the Test Cases selected by the Test Run configuration listed in the table.

  3. Select the first Test Case in the table. It's detail loads in the lower half of the page.

  4. Scroll down to the Execute Test section. If your project is configured for Test Steps support, this section contains the Test Steps from the Test Steps table in the Description field, and you can log the results of each individual test step.

  5. When you are ready to begin executing the test, click Start Test Case.

    While executing the Test Steps for a Test Case, you may find it necessary to pause the test execution and resume testing later. After you start executing Test Steps, the Pause Test Case button appears in the Test Steps. When you pause the test execution, the results of completed Test Steps are stored and the pause is recorded in the Test Run history. To resume testing, click Resume Test Case.

Tip:

It is possible that another user could modify the Test Case or Test Steps while you have paused test execution. If this happens, the Resume Test Case dialog box (if Test Case was revised) or Retest Test Case dialog box (if Test Steps were revised) appears.

  • Resume Test Case: Warns that you are no longer testing what was planned. For example, the Test Case was planned from HEAD revision, and the Test Case subsequently was updated while the Test Case was in progress. Or possibly, the revision in which the Test Case was planned changed (for example, frozen to a different revision in a Test Run where Test Cases are selected via the LiveDoc on Execute option). In both scenarios, after clicking Resume Test Case in the dialog box, the Test Steps remain the same, and you continue working in the revision in which you started.

  • Retest Test Case: Means that the Test Case (including the Test Steps) is updated and retesting needs to be done in the new version. If you click Retest Test Case, the Test Case is reloaded and execution is automatically started.

Executing Test Steps

If the Execute Test panel has multiple Test Steps:

  1. Click Start Test Case.

  2. Execute the first test step, note the result of the step in the Actual Result field, and click the button that indicates the result of the step: Passed, Failed, or Blocked. You can select from a list or previous results for the current step by clicking Recent (shown below).

    You can optionally attach a file (a screenshot image, for example) to the test step. An Add Attachment button appears when you click the Actual Result field. For more information, see Test Step Attachments.

    Reuse recent results.

    Caution:

    If the Test Case's Description field contains a table containing Test Steps, while it's possible to merge the cells in the table this not recommended.

    It may render the Test Steps unusable.

  3. Repeat the above for all Test Steps listed in the section.

  4. If there are multiple Iterations of the Test Steps, continue testing until you have completed all steps in all Iterations, or until something fails.

  5. (Optional) Enter a comment in the Test Case Verdict field and click on the button marking the overall Test Case result: Passed, Failed, or Blocked. If your project has been set up to require it, you are asked to log your electronic signature before proceeding further. A record of the signed test execution is then visible in test records and displayed in Test Cases, Test Runs, testing report pages, and so forth.

    If there are untested Test Cases in the table, and the Open next queued Test when finished option is selected, the next Test Case in the Test Run is automatically selected and ready for testing to begin on that Test Case. As long as the option is checked, this happens until all Test Cases in the Test Run are executed. In Test Cases with Iterations in the steps, the process proceeds through the Iterations before moving on to the next Test Case. The statistics in the Test Run Planning sidebar update to reflect the progress of the testing session.

    Note:

    It is not required to mark results for any of the Test Steps. You can mark all, some, or none. You need only log result of the Test Case: Passed, Failed or Blocked. However, Actual Result of every step is still written to the test record even though the test step has no verdict.

    Note:

    The Navigation scope can change depending on the setting in the Test Run's Project Span property. If multiple projects are specified in that setting, the scope switches to Repository. If just one project is specified, the scope switches to that project. If Project Span is empty, the scope remains in the current project.

    To return to the Test Run after selecting Test Cases, regardless of current Navigation scope, click on the Test Run name in the Test Run Planning sidebar. If not already open, the project containing the Test Run opens and the Test Run page loads in the browser.

Execute test cases without steps

If your project is not configured for Test Steps or if a Test Case does not contain multiple steps in a Test Steps table, then the panel in the Execute Test section of a Test Case contains only the Test Case Verdict field and buttons to mark the overall Test Case verdict of Passed, Failed, or Blocked. You can also add attachments to the Test Case Verdict using the Add Attachment link in the panel.

If the Execute Test panel does not have individual Test Steps:

  1. Click Start Test Case.

  2. Perform all the necessary testing activity to determine the result of the Test Case.

  3. (Optional) Enter a comment in the Test Case Verdict field, and click on the button marking the overall testing result: Passed, Failed, or Blocked. If there are untested Test Cases in the table and the Skip to the next Test Case after execution option is selected, the next Test Case in the Test Run is automatically selected and ready for testing to begin on that Test Case. As long as the option is selected, this happens until all Test Cases in the Test Run are executed.

Execute an unplanned test case

It is possible to execute a Test Case that has not been selected in a Test Run (That is, it has not been planned for execution in a Test Run). When the Test Case item is open and selected in the Work Items table, you can select a Test Run via the Current Test Run menu in the Test Steps panel of the Execute Tests section of the Test Case. When you click the Start Test Case button, if the Test Case has not been planned in the selected Test Run, a confirmation dialog box appears informing you that the Test Case is not planned in the Test Run. You are then asked to confirm that you want to execute the Test Case. You clickExecute to proceed, or Cancel to cancel the execution.

Execute or monitor multiple Test Runs simultaneously

Multiple Test Runs can be run simultaneously, even when they contain the same Test Cases.

  1. Launch two browser tabs with different Polarion Test Runs.

    The Test Run Planning Sidebar and browser URL displays the selected Test Run.

  2. The URL parameter, (containing the name of the originally selected Test Run), determines which Test Run is selected in the Current Test Run drop-down box when one of the Test Cases is opened or refreshed.

Sign executed Test Cases

Projects may be configured to require testers to electronically sign executed Test Cases. If your project is so configured, then when you mark the Test Case Verdict, a dialog displays requesting you to sign by entering your user name and password. See Signatures for Test Case Execution.

Reuse defect or issue Work Items

By default, any unresolved Defect (or equivalent type Work Item) from any Iteration in the current Test Run, or from any iterations in the previous Test Run (or the previous Test Run in the same group) is reused for failures of the same Test Case if the Test Case failed in the most recent execution.

In Test Runs that use Test Cases from different projects, this works differently. A Defect item can be reused only if it is linked to a test record in a Test Run in the same project as the current Test Run. This also applies to Failed in previous and Failed in group reuse strategies. For example, suppose "Project A" uses defect reuse strategy always. You execute a Test Case in a Test Run in this project which fails. The previous Test Run in which the same Test Case was executed is in "Project B". This previous execution failed, creating a Defect item that is not resolved yet. That defect, in "Project B", is not reused. Rather, a new one is created in the project specified in the testing configuration in "Project A".

Show an executed test for a finished Test Run

  1. Select a finished Test Run from the list of available Test Runs.

  2. Click Passed, Failed or Executed in the Test Run Status section.

    The Test Run's results appear in a list.

  3. Click Show in table.

  4. The Test Run's details appear.

Tip:

If you know the target Test Run you can also enter it directly as a search parameter.

(The results are read-only. Test Cases can not be retested in a finished Test Run.)

Test Step attachments

When manually executing a Test Run, you can optionally add a file attachment to each individual Test Step, or to a Test Record. For example, you might attach a screenshot image illustrating the result of a failed Test Step. This topic describes several important points you need to know about these attachments.

  • Click Add Attachment to attach a reference file.

  • Hover over an already-attached file and click to remove it.

  • You can attach a file to a test step or a test record, or remove an attachment from these, while testing is in progress.

  • Users can download attachments from Test Steps or the Test Records section of Test Case type Work Items in the Work Item Table view.

  • Users can download files attached to a test step result or a test record if the test record is visible on the page of a Test Run.

  • ​Users can download files attached to a test record if the test record is visible in the Test Run Records view.

  • Attachments are displayed in any Defect type items created as a result of failed test steps.

  • Attachments are not exported to, or imported from Excel during round-trip operations.