Page tree

This is the documentation of Xray Server. If you are looking for Xray Cloud, visit this page. Documentation of older versions of Xray Server is available in this page.

Skip to end of metadata
Go to start of metadata

Since Xray v3.1, you can receive email notifications related with Test Runs. This has been extended in v3.2 to provide notifications related with changes in Tests and Pre-Conditions.

Emails are sent depending on the configuration of Jira notifications, defined in a Notification Scheme, for some specific JIRA events provided by Xray.

Concerning Test Runs related events, since the Test Run is not an issue type, events are triggered for the related Test Execution; this means that the notification recipients fields are mostly related with the Test Execution. However, in some events there can be some difference on the semantics of the fields (e.g. "current assignee" may be the assignee of the Test Run instead of the Test Execution issue).

Usually, notifications are configured to be delivered to the "current assignee" (e.g. the Test Run assignee or the Test/Pre-Condition/Test Execution assignee, depending on the context). Nevertheless, it's possible to configure other stakeholders, such as the watchers, to be notified on the changes related with Tests/Pre-Conditions/Test Runs. 

How it works

Xray reuses the notifications mechanism provided by Jira; this simplifies a lot the management of Xray related notifications.

In other words, email notifications are triggered based on the configuration of notifications of events, in the context of the Notification Scheme being used by the project.

When Xray is installed, the following events are also installed (if they don't exist yet):

  • Test or Pre-Condition Updated
  • Test Run Assigned
  • Test Run Status set to Final
  • Precedent Test Run Status set to Final

However, by default, no notifications will configured for those events upon installation; you'll need to add, and therefore enable, them explicitly.

Global settings

There are some global settings related with Xray notifications. For more information on these settings, please see Miscellaneous.


Project Setup

Quick setup

Enable notifications

There is a quick setup, that will create a notification for each Xray related event and will configure it for the "current assignee".


Please note

This option will only be available if:

  • the user belongs to a group allowed to Enable/Disable notifications, accordingly with Xray settings
  • one of the Test Run related events has no notifications defined


To quickly enable Xray notifications, 

  1. go to project settings => Summary
  2. from the Actions menu, choose "Enable Xray notifications". Note that this will impact the Notification Scheme being used by this project and all other projects that also use it.
  3. For each Test Run related event, a notification will be created and assigned to the "current assignee"; please have a look at the Events section below, for clarification on the meaning of this specific recipient.

Disable notifications

There is a quick way to "disable" (i.e. remove) notifications for each Xray related event.


Please note

This option will only be available if:

  • the user belongs to a group allowed to Enable/Disable notifications, accordingly with Xray settings
  • one of the Xray related events has notifications defined


To quickly disable TXray notifications, 

  1. go to project settings => Summary
  2. from the Actions menu, choose "Disable Xray notifications". Note that this will impact the Notification Scheme being used by this project and all other projects that also use it.


Detailed setup

In order to enable notifications in some project, you need to:

  1. go to project settings => Notifications
  2. from the Actions menu, choose "Edit notifications". Note that this will impact the Notification Scheme being used by this project and all other projects that also use it.
  3. in each Test Run related event, click on "Add" in order to add a notification to the related Notification Scheme
  4. in the notification configuration page, besides the Event that will be pre-selected, define who shall receive the email notifications related with that event

     

Events

Test or Pre-Condition Updated

The aim of this event is to notify a user (or users) that the specification of a Test or Pre-Condition has been changed.

This includes:

  • adding/removing/updating steps in Manual Tests
  • updating the "Generic Test Definition" of Generic Tests
  • updating the "Cucumbert Scenario" of Cucumber Tests 
  • updating the "Conditions" of Pre-Conditions

The event is triggered for the related Test/Pre-Condition issue. This means that, in the notification configuration screen, most of the fields (e.g. "Reporter", "Project Lead", "Component Lead", "Project Role", "All Watchers", "User/Group custom field value") refer to the associated Test/Pre-Condition issue or to the Test/Pre-Condition issue's project. 


Please note

Changes on the typical fields (e.g. description, summary, etc) will trigger the standard "Issue Updated" event and won't trigger the "Test or Pre-Condition Updated" event.


Test Run Assigned

The aim of this event is to notify a user (or users) that a Test Run has been assigned, so the tester can proceed with testing.

This event is triggered whenever a Test Run is assigned to some user.


The event is triggered for the related Test Execution issue. This means that, in the notification configuration screen, most of the fields (e.g. "Reporter", "Project Lead", "Component Lead", "Project Role", "All Watchers", "User/Group custom field value") refer to the associated Test Execution issue or to the Test Execution issue's project. 

The exception is the "Current assignee", which is handled has being the user assigned to the Test Run and not the user assigned to the Test Execution issue.


Use cases:

  • Whenever a specific Test Run is individually assigned to some user (e.g. in the Test Execution screen), the "Test Run Assigned" event is triggered;
  • Whenever a Test Execution is created, all Test Runs are assigned by default to the Test Execution assignee. In this case, the "Test Run Assigned" event is not triggered (possibly, the user will be already notified because of issue created event);
  • Whenever several Test Runs are assigned to some user using the bulk operation, in the Test Execution screen, the user is asked if email should be sent (i.e. if the event should be triggered).


    Please note

    The "Send mail" option is only available if there is a notification assigned to the "Test Runs Assigned" event.

Test Run Status set to Final

The aim of this event is to notify users that a Test Run has been complete/finished (i.e. its current status is a final one).

This event is triggered whenever a Test Run is changed to a final status. For more information on final statuses, see Manage Test Statuses.


The event is triggered for the related Test Execution issue. This means that, in the notification configuration screen, most of the fields (e.g. "Current assignee", "Reporter", "Project Lead", "Component Lead", "Project Role", "All Watchers", "User/Group custom field value") refer to the associated Test Execution issue or to the Test Execution issue's project. 


Use cases:

  • Whenever a specific Test Run is changed to a final status (e.g. in the execution screen or as an inline change), the "Test Run Status set to Final" event is triggered;
  • Whenever several Test Runs are changed to a final status using the bulk operation, in the Test Execution screen, the "Test Run Status set to Final" event is triggered for each "Test Run".

Precedent Test Run Status set to Final

The aim of this event is to notify a user (or users) whenever a different user has finished running the previous Test, in the context of some Test Execution involving multiple testers.

This event is triggered whenever the previous Test Run (i.e. the one immediately before, accordingly to the ranking within the Test Execution) is changed to a final status and the Test Run assignee of the previous run is different from the Test Run assignee that follows it. For more information on final statuses, see Manage Test Statuses.


The event is triggered for the related Test Execution issue. This means that, in the notification configuration screen, most of the fields (e.g. "Reporter", "Project Lead", "Component Lead", "Project Role", "All Watchers", "User/Group custom field value") refer to the associated Test Execution issue or to the Test Execution issue's project. The exception is the "Current assignee", which is handled has being the user assigned to the Test Run and not the user assigned to the Test Execution issue.


Use cases:

  • Whenever a specific Test Run is changed to a final status (e.g. in the execution screen or as an inline change), the "Test Run Status set to Final" event is triggered;
  • Whenever several Test Runs are changed to a final status using the bulk operation, in the Test Execution screen, the "Test Run Status set to Final" event is triggered for each Test Run.


  • No labels