User Guide / Test Execution

Test Execution

An Execution Run is one pass through a set of test cases — a test cycle. This is where designed test cases actually get run and their results recorded.

Starting a run

Create an Execution Run against a project (optionally tied to a Test Plan and Release), give it a name and an environment note. Its status tracks itself automatically:

Not Started In Progress Completed

A run moves to Completed automatically once every test case in it has a final result, and reverts back to In Progress if any result is re-recorded afterward — you don't have to manage this by hand.

Recording a result

For each test case in the run, record:

  • Status — Not Run Pass Fail Blocked Skipped
  • An actual result note, and who it's assigned to / who executed it.
  • Evidence — attach a file, or paste a screenshot directly into the actual-result field.

Every re-execution of the same test case within a run is kept as history, so you can see exactly how a result changed across retests, not just the final answer. The Test Cases table on a run can be sorted by title, priority, severity, status, or when the case was created.

Reporting a bug from a failed result

When a test case fails, there's a Report a Bug action right on that result — it pre-fills the linked test case, the test suite, and the test plan for you, saving a trip to the Bugs screen.

Run reports

Once a run has results, you can export it:

  • Single-run report (CSV, Excel, or PDF) — the run's full results table with evidence links, and an optional public share link if you need to send it to someone without a login.
  • Consolidated report — every run in the project in one file (a page per run in PDF, a sheet per run in Excel), for when you need the whole picture at once instead of run by run.
Who can do this: creating runs and recording results is available to most testing roles on projects they belong to; a couple of roles (Business Analyst, Client) have read-only access to execution data.

Next: Defects →