Skip to content

Execute Tests Manually

Learn more

This page concerns test cases in Classic, BDD and Gherkin formats. To execute exploratory test cases, please refer to the Manage Exploratory Testing page.

Execute a Test Case

Execute a Test Case Manually

You can execute every test format manually: Standard, Gherkin, and BDD. You can start the execution from multiple locations:

  • from the execution plan, with the button Execution and the option "In a new popup";
  • from the execution plan, with the button Execution and the option "New execution";
  • from the execution's consultation page with the button [...] and the option "Start in popup";
  • from the execution's consultation page and the anchor Execution scenario by changing the execution status for every test step, adding comments and attachments, and reporting issues;
  • from the execution plan's item search page with the button Execution located at the end of each row in the search results.


No matter how you choose to execute the test, you can always start multiple ITPI (Iteration Test Plan Item) executions.
The ITPI status taken into account is the one from its last execution.


If a Gherkin test case's script is invalid and does not follow the Gherkin syntax, an error message appears at the start of the execution.

Follow this procedure to execute a test-case in a popup:

When you execute an ITPI in a popup, the following information appears during step 0:

  • An "Information" block with the test case's progress status, weight, nature, type, and description as well as the dataset used for the execution. There are also custom fields linked to test case entities (identified by an asterisk, cannot be edited) or executions (editable);
  • A "Prerequisite" block (for Standard test cases) or a 'Context' block (for Gherkin test cases) that contains the prerequisites to enter before executing the test;
  • A "Verified requirements" block containing the requirements linked to the test case. A clickable link enables you to view them from the table;
  • An "Attachments" block with the attachments linked to the test case. This block enables you to add three attachments linked to the execution.

Step 0 Execution Popup

By clicking on the button [Start] Start execution, step 1 of the test appears. It contains the following test steps:

  • the action and expected result of a classic test case's "N" test step;
  • the 'N' test case scenario of a Gherkin test case;
  • the 'N' test step action of a BDD test case.

For every execution step:

  • You can assign an execution status;
  • You can add a comment and attachements;
  • If custom fields were linked to the entities "Test step" or "Execution step", an "Information" block appears. The custom fields linked to the test step, which can be identified by an asterisk, cannot be edited as long as the ones linked to the execution steps are editable;
  • If a bugtracker is activated for the project, an "Issues" block appears for you to link or report issues;
  • Navigation arrows enable you to go from one sep to another. You can also change the number of the current test step to access another test step of the test case.

Step N Execution Popup

Execution Status

Executing a test consists in attributing an execution status to every test step or test case. From a pop-up execution, click on the status' colored dot to display the next test step.

Execution Status


You can activate the status "Settled" and "Untestable" in the project's configuration page, in the "Executions" block.

The execution plan contains a "Passed %" column that corresponds to the percentage of successful test steps during the last manual execution.

The status assigned to a test case corresponds to a priority order given to every status. Here is the order assigned to the main status. There needs to be only one test step with a higher status for the ITPI to also take that status:

  • "Blocked"
  • "Failed"
  • "Passed":
    • a test step with a "passed" status gives the ITPI an "In progress" status;
    • a test case only has a "passed" status if all its test steps have a "Passed" or "Settled" status.

For example: For this test case, only one test step has the status "Failed", so no matter the status of the other test steps, this test case will also have a "Failed" status.

Failed execution

Every tests suite's status is assigned according to the status of their tests. Priority is a notion that is also applicable to test suites.

For example: For this suite, only one test has a "Blocked" status. So no matter the status of the other tests, the suite will also have a "Blocked" status.

Blocked Suite

Execute a Test in Fastpass Mode

It is possible to execute a test in Fastpass mode without executing all of its test steps. For this, in the execution plan, change the ITPI's execution status in the "Status" column. The ITPI's previous executions (without Fastpass) are kept.

Fastpass mode is not considered an execution by itself. Therefore, there will not be any execution details page such as with the popup, nor any row for the execution in the "Executions History" popup.

Execution in fastpass mode

Start Successive Executions of Multiple Tests

The block Execution plan of an iteration or test suite contains action buttons enabling you to execute successive tests.

The [Start] Button

The [Start] button Start execution is there by default if no execution was started in the iteration or tests suite.

When you click on [Start], you can execute all the tests in the execution plan successively via the execution popup.

The buttons [Resume] and [Restart]

When you stop successive executions even though there still remains test steps to execute, you can resume these executions with the [Resume] Resume execution.

If all the tests in the execution plan were executed at least once, the button [Restart] appears on the page of the execution plan. This enables you to restart the execution plan's tests by deleting all the previous executions.


The button [Restart] deletes all the previous executions of the ITPIs contained in the execution plan.


  • You can directly go to the next test case by clicking on the button Next in the N steps in the popup.
  • W-hen all the test steps are executed, a popup appears to inform you that the tests are finished.

Modify a Test Case In Progress


  • To modify a test case in progress, you must activate this feature on the project's configuration apge, in the "Executions block";
  • Only the test cases in Standard format can be modified during the execution.

You can modify a test case in progress by clicking on the button Modify a test case during its execution in a test case's execution steps. You can modify its general information and steps.

Modifying the Test Case at Step 0

At step 0, in the execution pop-up, click on the button Modifying the Test Case during execution. The test case's details page appears. You can then modify all the information of the test case.

From this page, click on the button [Go back to the execution] Comeback to execution to go back to step 0 of the execution. The changes made appear in the execution popup.

Modify the Test Case at Step N

At step N in the execution popup, click on the button Modifying the Test Case during executionn. The test step's details page appears. All the test steps as well as their links to requirements can be modified. From this page, you cannot add or delete test steps.

From this page, click on the button [Go back to execution] Comeback to execution to go back to the execution. The execution popup opens the first modified step (first as per execution order). The status of the test steps already executed take the status "To be executed" again.

View a Test's Executions History

The status history of ITPI executions can be accessed directly from the execution plan in the form of status bars (maximum 5 status bars). A dot displays the status of the last ITPI run. When the bars are hovered over, a tooltip displays the status, date and time of the execution. A status defined as 'Fastpass' is never shown in the execution bars.

History of test executions from the execution plan


Whatever the launch mode (manual or automatic), the execution history is displayed in the form of bars in the status column.

You can access an ITPI's executions history via the button Execution and the option "Executions history" for an execution plan's every ITPI.

The "Executions history" popup appears and lists all the ITPI's executions, with their test step percentage with a passed status, their execution status, the user who executed the test, and the last execution date.

From this popup, you can also delete an execution.

A test's executions history

From the Test Cases workspace, you can also view all the executions of a test case by clicking on the Executions anchor of the desired test case. As a reminder, a test case can contain multiple executions for one of these ITPIs and can be executed in multiple iterations or tests suites.

Execution Consultation Page

You can access an execution's detailed consultation page by clicking on:

  • the link in the date in the column "Last Exec." in the execution plan;
  • the execution's number (column "Execution Nb"), in the popup "Executions history".

An execution's consultation page has several anchors:

  • the "Information" anchor which contains th test case's progress status, weight, description, nature and type, as well as the custom fields linked to the test case (uneditable) and to the execution (editable);
  • the "Verified requirements" anchor contains the requirements linked to the test case;
  • the "Comments" anchor to view or add a comment on the test case's execution.
  • the "Issues" anchor to view or link issues to the test case during its execution.


The "Issues" anchor only appears when a bugtracker sever is linked to the project in the administration.

These first 4 anchors appear no matter the format of the executed test case.

Execution consultation page anchor

Standard Test Case

The anchor "Execution scenario" contains the test case's Prerequisite as well as all the test steps' following information:

  • execution status;
  • execution date and user login;
  • content of the blocks Action and Expected result;
  • a sidebar "Custom fields linked to the test step (uneditable) and to the execution step (editable);
  • a "Comments" sidebar;
  • an "Attachments" sidebar;
  • an "Issues" sidebar.

Classic test case execution scenario

Gherkin Test Case:

The "Script" anchor contains the Context as well as every test scenario from every execution step's following information:

  • execution status;
  • execution date and user login;
  • the script of an execution scenario;
  • a "Comments" sidebar;
  • an "Attachments" sidebar;
  • an "Issues" sidebar.


  • If the Gherkin script contains a scenario plan, it will be translated into as many execution steps as there are datasets in the examples table. Thus, a Gherkin test case is never linked to a Squash TM dataset.
  • In a scenario plan's execution steps, Gherkin parameters (in between <>) are replaced by their values in the example line considered.
  • If in the script the language tag is correctly filled, the execution takes into account the syntax highlighting of keywords.
  • If the language tag is invalid, the script is treated as if it was written in English.

BDD Test Case:

The "Execution scenario" anchor contains all the execution steps with the following information:

  • execution status;
  • execution date and user login;
  • Action block content;
  • "Comments" sidebar;
  • "Attachments" sidebar;
  • "Issues" sidebar.

An execution's consultation page enables you to view or modify an execution that was already done; but it can also enable you to start a new execution from the execution plan with the button Execution and the option "New execution".