A Test Run (sometimes simply referred as a "run") results from the scheduling of a Test for execution within some Test Execution.  Therefore, each time you run some Test, you're in fact running a Test Run.

A Test Run is an internal instance of a Test scenario, that is used to validate some specific version of source code/SUT, in a specific environment. Various test runs allow to easily detect defects in the code that could lead to system failures.

A Test Run is not a JIRA issue itself; it's an Xray internal entity that you can search (see Enhanced querying with JQL).

Normally, you may see Test Runs within specific panels, namelly in a Test Execution (a test run per each test) or within the Test issue screen (history of previous runs for that test).


A Test Execution represents a task for running several Tests. It contains as much Test Runs as the amount of Tests associated to it; to be precise one Test Run per associated Test, in order to track the result for each Test.


 

What is stored in a Test Run

A Test Run contains a copy of the testing specification of the Test and associated Pre-Conditions. This specification only comprises some fields of these entities; thus, not all fields are copied to the Test Run.

As an example, general custom fields, summary, description fields are not persisted in the Test Run. Thus, you should avoid using those fields to add "relevant" information to the test specification. 

Depending on the original type of  the Test associated with this Test Run, these are the fields are persisted within the Test Run.


Manual TestsCucumber TestsGeneric Tests
Test
  • Test Type
  • manual steps
  • Test Type
  • Scenario
  • Test Type
  • Generic Test Definition
linked Pre-Condition(s)
  • Pre-Condition(s) Type
  • Conditions
  • Pre-Condition(s) Type
  • Conditions
  • Pre-Condition(s) Type
  • Conditions


Since a Test Run is related with the execution of a Test, obviously it also contains comments and information about linked defects and evidences (i.e. attachments).

Data consistency

Test Runs represent the results of running some Test specification at some moment in time, in the context of some Test Execution. Thus, they assure data consistency as will see next.

So, what happens if you change the Test specification at any time?

In this case, your existing Test Runs are not changed (unlesss you want to), in order to assure data consistency and compliance with conformance regulations.

At the execution screen of a given Test Run, you will be presented with two options:

  1. Merge current Test specification with the current specification persisted in the Test Run
  2. Reset the current Test Run, by copying the current Test specification to the Test Run and discard all recorded results


More information on these actions can be found in Execute Tests

Merge existing Test Runs

dd

Update/Reset existing Test Runs

dd

Execution History

The execution history of a given Test issue is available in the Test issue screen in the section named "Test Runs".

The Test Runs section is headlined by the Test Runs Filter, that allows the user to sort for:

The search results are displayed on the table immediately under the Test Runs Filter, containing the following columns:

Actions

The following actions are available in the Test issue screen.

The "Execute Test" and "Execute Test Inline" may also be available in similar Test Runs sections that may be present in other places.

Execute Test

To execute a Test from a Test issue:

Step 1: Open the Test you wish to run.

Step 2: Click the Execute button that appears in the last column of the desired Test Run. The actions menu should popup with the available actions.

Step 3: Click Run action to open the Execution page.

Execute Test Inline

To execute Test Runs inline from the Test issue screen, this option must be enabled in the Xray administration page. The option for setting the Test Run status manually, without having to execute all Test Steps (or Examples in case of Cucumber Tests), must also be enabled in the Xray administration page.

Given that the above options are enabled, and the user has permission to execute the Test, the context menu for executing Test Runs, accessed be the Execute button on each Test Run must show the available transitions. 

When executing inline Tests, the status of the manual steps (or Examples in case of Cucumber Tests), can be changed automatically. The following rules are applied:

To execute a Test Run inline:

Step 1: Open the Test issue you wish to run.

Step 2: Click the Execute button located in the last column of the Test Runs table and select one of the available statuses.

 

View Test Execution Details

To view the execution details:

Step 1: Open the Test issue you wish to view the test execution details.

Step 2: Click the Execute button that appears in the last column of the desired Test Run that is in a final state. The actions menu should popup with the available actions.

Step 3: Click Execution Details action to open the Execution page and view the details.

Ad hoc Test Execution

To execute a test in an Ad hoc manner:

Step 1: Open the Test issue you wish to execute.

Step 2: Click the "Execute In" button in Test Runs section and select "New Test Execution..."

Step 3: The dialog comes with pre-populated fields so if you don't want to change anything just click Create.

Note: if there are custom required fields the normal issue create dialog will be displayed with the pre-populated fields. If the revision field is not configured in the create issue screen, of the Test Execution for the selected Project, the field will not appear in the dialog.

If the Redirect To Execute Test Page option is selected you will be redirected to the Execute Test page after the test execution is created.