Test Execution (in Projects module)

Test execution is another important part of the project. When you run tests, you test TCs (test cases) and change their statuses according to the result. There are 5 types of statuses:

  • No run
  • Passed
  • Failed
  • N/A (not available)
  • Not completed

Selecting a test sprint

When you first open the Test Execution, you’ll only see the top row and two fields in it. After selecting the test plan and test sprint, you’ll see a list of TCs that are being tested. In the picture, you can see the main table with the basic functionalities: open, table settings, filter and column display settings.

In the tests overview, you can also see the tags – you can also filter the test cases by tags. This can be used when filtering test cases that can be retested.

By clicking on the “Open” button a pop-up window will appear. In the header (in the picture) you’ll find 4 important parts:

  • Application, environment, module (information about the displayed TC)

  • Priority
  • Status (the superior status of TC – the selected status can be changed, but the default status is automatic)

  • Timer is the header’s most important part. Therefore, to start working, you must turn on the timer and turn it off again when you’re finished.

Let’s return to the STATUS functionality in the header. The default setting is automatic even though it can be changed. When you select and confirm one of the header’s other statuses, the status of each step (subordination to the header status) is changed.

For example: We tested the test case and the status of one test step failed. However, after the bugfix, we want to retest the TC. Therefore, we can open the TC and set the status to no run in the header. The status of each step will be changed to no run.

Testing window functionalities



Now, you can see a window that contains detailed information regarding the TC (name, test data, requirement version, steps). The steps are the most important. After turning the timer on, you can change the status of the given step, then confirm the selected status and go to the next step.

For example: When testing a TC, we open the application and perform the precondition check. Then, we compare the result with the expected result and change the TC status accordingly.

When you’ve finished testing the test case, you must stop the timer and close the window. The line with the tested TC changes its colour according to the state of the steps.

  • All steps are passed, TC is in the same status (green colour).

  • If one of the steps is not passed, the status will be marked as not completed (yellow colour).

  • If any of the test steps is failed or not completed, the status will be marked according to the specific step (red or yellow colour).

  • If the steps are marked as passed and N / A, the entire status will be passed (green colour).

History of test step

In each row you can see the “history” where all TC changes are recorded.

Result of test step

Here you can see the TC result and add comments or attach a file to any step.


When marking a step with a failed status, the options “issue” and “assign issue” appear. You can use “issue” to report a problem that you describe in the test step. Usually you test a flawless TC, however if you find a bug, see more details about reporting issues “here“).

There is also a second way how to link the issue to the test step, using the “assign issue” button – you’ll see a window where you’ll be able to find the issue that has already been created. This is used when an issue blocks multiple test cases.

Group actions

Group action is a specific function of this module. You can use this action to change the statuses of multiple test cases (Note that this action changes the status in the TC header!).