You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Xray provides a set of custom fields that can be used for some issue types as detailed in Custom Fields and Screen Configuration.

Besides this, you can add your own custom fields to any Xray issue type: Tests, Pre-Conditions, Test Sets, Test Executions, Test Plans.

Currently, you can't add custom fields to Test Runs since they're not JIRA issues.


Xray provided custom fields

As mentioned in Custom Fields and Screen Configuration, whenever you install Xray it will also add some custom fields. Bellow, please find a more detailed explanation of some of the most important ones.

Requirement Status

Whenever we're speaking about status associated with a requirement, we may in fact be talking about different things:

  • workflow status associated to the requirement issue (e.g. "New", "In Progress", "Closed")
  • (coverage) status for some version, taking into account executions made for that version of the Tests that do validate the requirement
  • "Requirement Status" custom field

The "Requirement Status" custom field is a calculated field, usable in the context of requirement issues, that calculates the requirement coverage for a specific version. The version that it calculates the coverage for depends on the behavior for that field defined in a global configuration (see configuration details here).

As an example, you may prefer to always calculate this based on the latest test run(s), independently in which version it/they was/were executed... or you may prefer to calculate it for the earliest version yet to be released (i.e. the next version). In the later case, it takes into account the order of the versions within the project settings page.  

Have in mind that a requirement  is assigned to and implemented in some version. However the requirement will still live after that version, at least for some time. Therefore, when someone mentions a "status of  a requirement", you have to ask "In which version?". The status of the requirement is thus dependant on the executions you make for the associated Tests in some version of the system, which may by different from the version in which the requirement was initialy implemented in.

This field is non-searchable.

TestRunStatus

The "TestRunStatus" is a calculated field, usable in the context of Test issues, that calculates the "status" (not the workflow status) of the Test for a specific version, having in mind executions (i.e. test runs) for that version. The version that it calculates the status for depends on the behavior for that field defined in a global configuration (see configuration details here).

The calculated value for the field also depends on Test Environments, if they're being used, as mentioned here. As an example, you may prefer to always show the latest test run result independently in which version it was executed... or you may prefer to show the status of the latest run executed on the earliest version yet to be released (i.e. the next version). In the later case, it takes into account the order of the versions within the project settings page.  

You can add this field to the Test


This field is non-searchable.

Test Set Status

dd


This field is non-searchable.

Adding your own custom fields

You may add CFs to Tests, however they’re not copied to the Test Run. Custom fields at Tests can be seen as complementary, non-relevant information.

But adding custom fields is not limited to the Test issue type; they can also be added to other Xray issue types, including the Test Execution and the Test Plan. For example, in the Test Execution you could add a custom field to identify the browser version.

Recommendations

  • Don’t reinvent the wheel; use standard fields, such as labels and components, and avoid creating custom fields without need
  • Remember that custom fields added to Tests are not copied to Test Runs, so they’re volatile/informative only; they’re not part of the specification
  • No labels