Overview
This document provides general guidance on how integration with Xray can be achieved.
Not all possible usage scenarios are covered in this document, as 3rd party tools have different capabilities and different usage usage patterns.
Please have in mind that Xray is a product that is continuously evolving, so you should look at the available capabilities periodically.
Another important aspects is that Xray Server/Data Center(DC) and Xray Cloud are distinct products, with different capabilities (additional info ahead). Specific information for each product will be highlighted using the notation (server/DC, cloud), with respective links.
If your goal is to support both Xray on Jira server/DC and Jira Cloud, you'll have to make two different implementations; the differences may be subtle.
Some questions to answer before implementing the integration:
- What are the use cases for the integration and corresponding flows? Where will entities will be created? Can we easily navigate/jump between tools, to the right context?
- What information do I want to show in Xray? How valuable is it from the Xray user perspective? Can we even make it more valuable?
Background
Xray concepts
In Xray, testing concepts are implemented either as issues or as internal entities.
Not all concepts are, or need to be, used by teams. Some concepts may address similar purposes (e.g. Test Set and Test Repository) but have distinct capabilities.
Many of Xray core entities are standard Jira issue types. Therefore they can be managed as any other Jira issue and standard Jira features are also available for them; more info here.
Issue Type | Description/Purpose |
---|---|
Test | An abstraction of a test idea, usually a test case. It may be composed of multiple steps, actions and expected results or it may be a gherkin scenario or even just have an abstract definition (e.g. a charter). Usually a Test is linked to a requirement/user story. |
Pre-Condition | Initial conditions that must be assured before the execution of the Test's own steps. A Pre-Condition may be used by multiple Tests. |
Test Set | A group of tests, organized in some logical way. A flat list of tests that doesn't contain results. |
Test Plan | A "formal" plan of the tests intended to be executed for a given version or sprint. Used for grouping multiple Test Executions and presenting a consolidated overview of them; tracks the results of some Tests in some version/sprint of the System Under Test (SUT). |
Test Execution | An assignable, "schedulable" task to execute one or more tests for a given version/revision along with its results. A Test Execution can be linked to a Test Plan, and if so results will be visible on that Test Plan. A Test Execution may have a
|
Sub-Test Execution | A Sub-Test Execution has the same functionalities as the Test Execution issue type. The difference between them is that the Sub-Test Execution is a sub-Task and can be created in a requirement's context. Creating a Test Execution as a sub-task from within the requirement issue screen will provide the user the ability to track executions in the Agile board. A Sub-Test Execution has also the same attributes as a Test Execution. |
Some entities/concepts are internal to Xray are therefore not Jira issue types. The Test Run is an example of one.
Other Entities | Description/Purpose |
---|---|
Test Run |
|
Test Repository |
|
Test Plan Board |
|
Test Environment | An attribute of a Test Execution that identifies where testing was performed. Depending on your context, a test environment may represent:
More info here. |
Xray server/DC vs Xray Cloud
Although similar, Xray for Jira server/Data Center(DC) and Xray for Jira Cloud are different products, essentially because they are built on top of different infrastructures and application capabilities. Jira server/datacenter and Jira Cloud are distinct products, with different roadmaps, built using distinct technologies, and providing different APIs. This has a consequence that apps for Jira server/DC and for Jira Cloud are essentially totally different from an architecture standpoint, but eventually also from a feature perspective.
Jira server/DC provides certain customizations capabilities, which may not be available on Jira Cloud.
From an integration standpoint, there will always be changes if a 3rd party wishes to integrate with both Xray server/DC and Xray Cloud. However, these can be subtle, depending on the flow to be implemented.
Preparing a environment with Xray to test the integration
To test out the integration with Xray, first of all you'll need access to a Jira server/DC instance or a Jira Cloud instance. The instance needs to have the respective Xray product installed and configured, which also requires having an Xray "enabled" project to play around.
What do you mean with "enable" Xray in a project?
Xray doesn't provide a "enable" kind of action for projects. You should read it as "configured" instead.
Xray is a flexible tool, so you can "enable" it in different ways. Most times, this ultimately is materialized as adding the Xray issue types to the project and enable coverage on the project.
For Jira server/DC:
- you can use a public sandbox environment to start immediately; note that this environment is shared with other users and is reset weekly, on Sundays. This environment already has Jira and Xray installed and it contain a sample project called BOOK, with some existing test data. You'll need to create an account in this instance.
- to install and configure Xray on your local Jira environment ,
- see Installing instructions. A trial version is fully functional for a 1 month period which may be extended
- see Quick Setup instructions, to create a Xray enabled project; you can create a standard project and then add Xray issue types and enable coverage for the project
For Jira Cloud:
- to install and configure Xray on your local Jira environment ,
- see Installing instructions
- see Quick Setup instructions, to create an Xray enabled project. You can create a Scrum project, for example, and then follow the previous instructions.
- in Jira Cloud there are company and team managed projects, which are quite different. Xray supports both but please make sure you follow the right setup instructions
Integration possibilities
Xray server/DC
The most common way of integrating with Xray server/DC is by using the Xray REST API.
Usage scenarios | Notes | |
---|---|---|
Jira REST API |
| Creating and modifying issues using Jira's REST API is limited to typical fields; usually, Xray internal data cannot be modified this way. |
Xray REST API |
| The most common and preferred to integrate with Xray. |
Custom field on Xray issues | In Jira server/DC, custom fields may have custom logic; this usually requires the development of a custom Jira app/plugin. | |
Web panel on Xray issues | In Jira server/DC and Jira cloud it's possible to add web sections/panels on the screens of issues (i.e., view issue screen). This requires the development of a custom Jira app/plugin. |
Jira's REST API and Xray REST API
Xray uses Jira issues for implementing Test, Pre-Condition, Test Set, Test Execution, and Test Plan entities. Therefore, these entities may be created or updated using Jira's native REST API, taking into consideration Xray's custom fields.
The Xray REST API provides additional endpoints specifically made for dealing with test entities/fields and importing execution results from automated processes.
Authentication
Jira 8.14 introduced the concept of Personal Access Tokens, which Xray takes advantage of. These tokens can be created in the user's profile section in Jira and have an expiration date; they can also be revoked at any moment (more information here).
To use them in Jira's and in Xray REST API calls, we need to use the HTTP header "Authorization" with the "Bearer <token>" value.
You may also use HTTP basic authentication with some user credentials.
Xray Cloud
Xray Cloud provides a REST API to handle more heavy and time-consuming operations such as importing executions results, generating cucumber feature files and importing Tests.
Besides, there's a GraphQL API which allows users to perform CRUD operations directly on Xray entities. GraphQL gives clients the power to get exactly what they need and nothing more, in one call.
Both APIs use the same authentication mechanism as shown ahead.
Authentication
The authentication process uses a Client Id and a Client Secret, both of which are based on an API Key created for a specific user in Xray Global Settings: API Keys global settings.
Thus, the first step for you is to obtain a token based on the Client Id and Client Secret of your assigned API Key. You can then use any GraphQL or REST API end points.
Tokens are valid for 1 day.
# authentication request with client id and client secret passed inline curl -H "Content-Type: application/json" -X POST --data '{ "client_id": "32A27E69B0AC4E539C14016437000000","client_secret": "d62f81eb9ed859e11e54356dd8a00e4a5f0d0c2a2b52340776f6c7d6d7000000" }' https://xray.cloud.getxray.app/api/v2/authenticate # or, if you have the client id/secret stored in a file (e.g. cloud_auth.json) having the content syntax as { "client_id": "xxx","client_secret": "xxx" } curl -H "Content-Type: application/json" -X POST --data @"cloud_auth.json" https://xray.cloud.getxray.app/api/v2/authenticate
Typical use cases
Importing test automation results to Xray
Importing automation results into Xray is a very common use case.
At high-level, the flow can be depicted in the following diagram.
There are some initial steps that need to be performed on the tool prior to importing results. The creation of the Test issue in Xray, could be done at any moment prior to importing results(manually or via the API).
The recommended way for importing results is by using the Xray JSON format and one of the respective endpoints (server/DC, cloud), which is quite flexible and very straightforward if you wish just have overall visibility of the test result, for example.
There are also other well-known formats, each one providing different capabilities (server/DC, cloud).
Other alternatives
Another approach, since many tools provide it by default, is to import results using JUnit XML, which can also be used to auto-provision Tests issues in Xray, unless they already exist. However, this format lacks the ability to provide additional information that Xray can provide. So, even though it may work, the data is superficial and using the Xray JSON format is preferred.
Before implementing the integration, review the following questions to help guide your implementation approach.
Question | Possible answers | Tip |
---|---|---|
What kind of information do we need to see in Xray for each test result? |
| Each Test Run has always these attributes:
Depending on the type of Test (i.e. Manual, Cucumber, Generic) additional fields may be available.
|
Do we need to create the Test entities in Xray or will be reporting test results against existing Test issues? |
| Usually, tools report results against existing Test issues in Xray. |
Can we report test automation results against an existing "manual" test case? |
| The Xray JSON format allows you to specify results for "Manual" (i.e., structured) tests, including for each step. |
Do I need to know the type of test whenever importing the results? | Yes, because the format for reporting results is different from test type to test type, due to their kind (i.e., whether they are composed of steps or not, or if they are gherkin) | |
Should we create defects (e.g.m Bug issues) automatically in Jira? | Usually no, as defects are mostly a consequence of analysis and a human decision. |
Examples
Scenario1: report test automation results to existing Tests in Xray
In this case we're assuming:
- Test issue(s) already exist in Xray (they could have been created as usual by a user or by some automation process)
- An automated test equivalent exist in the external tool, for each Test
And we want to...
- report test automation result back to the existent Test issue(s)
The following request shows how to import results for two tests, identified by their issue keys. The first one failed while the second passed.
Both tests were performed against version 1.0 of the SUT, using the Chrome browser; since it is relevant for us to analyze the results later on from each browser perspective, we map the browser name to a Test Environment.
On the failed test, we leave a comment on the Test Run and also attached a screenshot as evidence.
Xray server/DC
After importing results, a Test Execution would be created containing the results for the two tests; the details of the execution screen show the data of the Test Run, including its status, comment, timings, among other.
Xray Cloud
After importing results, a Test Execution would be created containing the results for the two tests; the details of the execution screen show the data of the Test Run, including its status, comment, timings, among other.
Scenario2: report test automation results to existing Tests in Xray, with additional step-like detail
This use case is very similar to the previous one; the main difference is that we aim to provide more detailed information on the results for each test, including having visibility of each "automated step/action/assertion".
In this case we're assuming:
- Test issue(s) already exist in Xray (they could have been created as usual by a user or by some automation process)
- An automated test equivalent exist in the external tool, for each Test
And we want to...
- report test automation result back to the existent Test issue(s), where we want to see the step-level details (i.e. results for the assertions performed by the test automation script)
The following request shows how to import results for two tests, identified by their issue keys. The first one failed while the second passed.
Both tests were perfomed against version 1.0 of the SUT, using the Chrome browser; since it is relevant for us to analyze the results later on from each browser perspective, we map the browser name to a Test Environment.
On the failed test, we leave a comment on the Test Run and also attached a screenshot as evidence. On the Test Run we can see the results for all the steps/assertions performed by the automated test.
Xray server/DC
After importing results, a Test Execution would be created containing the results for the two tests; the details of the execution screen show the data of the Test Run, including its status, comment, timings, among other.
Xray Cloud
After importing results, a Test Execution would be created containing the results for the two tests; the details of the execution screen show the data of the Test Run, including its status, comment, timings, among other.
Tips
Use wiki markup to not only to format text but also to provide additional information or access to it
The following fields support Jira wiki markup, so you can use formatting in several fields (Jira related and Xray specific):
- Description field of Test Execution
- Overall comment on Test Run
- Actual Result and Comment fields on the steps of Test Run (only for Test Runs of step-based Tests, such as "Manual" Tests)
There can be some subtle differences between Jira server/DC and Jira Cloud, so we advise you to try it out on both deployment types.
What can it be used for?
Some ideas:
- On the Description field,
- provide a link to the external tool, where users can see the results for that batch execution as a whole
- provide some table, or some bullets, with some additional info about the context of the batch execution and that thus apply to all results (i.e. Test Runs)
- embed a image (e.g. a chart); image must be stored in some accessible URL; it's also possible to atach a image on the Test Execution issue but that would require a separate, Jira specific, call after importing the results
- On the overall comment of each Test Run,
- provide a link to the external tool, where users can see detailed results for this specific Test Run
- On the Actual Result, or on the Comment fields of each step (only for Test Runs related to step-based/structured Tests), highlight some information using bold
Attach files (e.g. screenshots) as evidence
During the execution of automated test scripts, some evidence may be produced. Usually these can be screenshots, a video recording of the whole session, page source, or log/dump files.
Even though we should not mix up Xray with a CI/CD tool, these files can be helpful for providing an immediate analysis capability, right on Xray.
What can it be used for?
Some ideas:
- On the overall evidence of each Test Run, no matter the type of Test,
- to attach a video recording of the session
- or to attach screenshots that were taken by the test script; screenshot names could be prefixed or suffixed with a number to help out identify them better (e.g. 1_screenshot.jpg, screenshot_1.jpg). The latter can be helpful for generic/unstructured Test Runs, where steps as such are not available
- On the evidence of each step (only for Test Runs related to step-based/structured Tests), attach
Are there any constrains on evidence/attachment size?
On Xray server/DC,
- similarly to what happens with attachments on Jira issues, Test Run evidence are stored as attachments on the parent Test Execution issue; this means that the global setting for Jira attachments also apply to Test Run related attachments. Attachments are stored in a local folder in the Jira server/DC instance
On Xray Cloud,
- standard Jira issue attachments are stored in Jira Cloud's infrastructure; there are some constraints on the size limit and total space for attachments. Xray data, including evidence/attachments added at the Test Run level, are stored in Xray Cloud infrastructure; in this case, please see Xray' storage documentation.
No matter the deployment type, we advise not to upload very large files (up to a few tens of MBs).
Implementation Checklist
Make sure your tool provides these:
- Xray and Jira configuration
- Xray server/DC or Xray Cloud ?
- Server/DC specific settings
- Use Jira username/password or Personal Access Token?
- Jira username
- Jira password
- Personal Access Token
- Cloud specific settings
- client id
- client secret
- On the test tool, associate the project to a Jira project
- identify Jira project by its key,
- specify the Jira project version, to identify the version of the application that is being target by testing
- On each test on the tool, associate it to an existing Xray Test issue
- specify Test issue key
- If the tool provides a concept of a group of tests to be executed/orchestrated, and where then users can see the results of each iteration, then optionally associate to this group:
- Test Plan, by specifying its issue key
- Test Environment, by specifying its name; in Xray Cloud, the Test Environment needs to be defined on the Xray project settings
Provide links on Xray entities to external entities to facilitate navigation
Sometimes it may be useful to provide a way to quickly navigate from a Xray entity (e.g. a Test, Test Execution, Test Plan) to the corresponding entity in the external tool.
The general flow can be depicted on the following diagram.
There are several ways to accomplish it; however, we recommend creating a new specific custom field (e.g. "ExternalRef") for this purpose. You can reuse this field for different issue types, in case they have their corresponding flavour on the external tool.
Examples
Scenario1: provide a link on Xray Test issues to the corresponding test in the external tool
In this case we're assuming:
- Test issue(s) already exist in Xray (they could have been created as usual by a user or by some automation process)
- An automated test equivalent exist in the external tool, for each Test
And we want to...
- be able to identify the test ID on the external tool and easily navigate to it right from the Test issue screen
The implementation would be exactly the same in case we want to provide this capability for other Xray entities, such as Test Execution or Test Plan issues, if they have a counterpart entity on the external tool.
Xray server/DC
As the API call is made on Jira server/DC REST API, we need to use its authentication mechanisms (e.g. basic authentication or Personal Access Tokens).
After making the request, the Test issue will have the our field (i.e. ExternalRef) with a link to the test on the external tool.
Xray Cloud
As the API call is made on Jira Cloud REST API, we need to use a Jira Cloud API token created manually beforehand.
After making the request, the Test issue will have the our field (i.e. "ExternalRef") with a link to the test on the external tool.
Implementation Checklist
For this purpose, please make sure your tool provides these:
- Xray and Jira configuration
- Xray server/DC or Xray Cloud ? (which implictly will define if Jir server/DC or Jira Cloud are being used)
- Server/DC specific settings
- Use Jira username/password or Personal Access Token?
- Jira username
- Jira password
- Personal Access Token
- Cloud specific settings
- Jira username
- Jira API Token
- On each test on the tool, associate it to an existing Xray Test issue
- specify Test issue key
Create/update test(s) in Xray
In Xray Tests are usually associated with Requirements (either being a User Story, Task, Epic, or other issues your team uses), this is usually how teams work and will allow Xray to calculate the Coverage.
Regarding the flow of interacting with external tools the most common case is the one where the Test is already defined in Xray and the execution is done in another tool (like a test automation tool), having the need to import those execution results back to Xray (as described above).
Ideally when you create a new test in the test automation tool you should create a Test in Xray that will be his counterpart (this is to prevent having the need to manually create those), in order to link the execution results to the same Tests. However this may imply the need to update the Test (in Xray) each time it is changed in the eternal tool, so please take this into consideration when choosing to implement this integration.
At high-level, the flow can be depicted in the following diagram.
In Xray we can create three types of Tests:
- Manual, are user-assisted tests, listing an assortment of guidelines the user must follow, and the results that such behavior is expected to accomplish. They use steps with action, data and expected result to define a manual Test.
- Generic, is an agnostic Test that does not contain any structure. The only field that is related to a Generic Test is its Definition. For an automated test, the Definition field can have an ID or name that maps to the external automated Test case. An example might be a JUnit test created automatically by Xray when the JUnit XML report was imported with test results. Usually the ones used for automation as we only have one field where an unique identifier is expected that will be used by Xray to be able to connect back the executions.
- Cucumber, Cucumber is a tool that executes plain-text functional descriptions as automated tests. The language that Cucumber understands is called Gherkin, which is a business-readable, domain-specific language that describes the software’s behavior without detailing how that behavior is implemented. Gherkin is a line-oriented language that uses indentation to define the structure. Line endings terminate statements (e.g., steps). Either spaces or tabs may be used for indentation (but spaces are more portable).
For the following examples we will provide one example of each type.
Before implementing the integration, review the following questions to help guide your implementation approach.
Questions | Possible answers | Tips |
Do I want to link the Test to a Requirement? | No, we only want to see the execution results in Xray and do not use the coverage report or will link it by hand afterwards. Yes, I will provide the requirement in the request to create the issue to be linked since the start. | Coverage is a great asset that will bring visibility to all the elements of the team about the overall status of the release/project. |
Do I need to know the type of test whenever creating a new Test? | Yes, because the format for creating tests is different from test type to test type, due to their kind (i.e. whether they are composed of steps or not, or if they are gherkin) | |
Can I differentiate these Tests from the “normal” ones created in Xray? | Yes, you can add an extra label that can be used in filters or add a link to the corresponding Test detail of your tool. | Adding an endpoint in the Test for the users to be able to jump from one tool to another easily is very useful. |
Examples
Scenario1: creating Test(s) in Xray
In this case we're assuming:
- Requirements(s) already exist in Xray (they could have been created by a user or by some automation process)
- An automated test equivalent exist in the external tool, for each Test
And we want to...
- Create the “same” test(s) in Xray
The following request shows how to create Tests (of different types) in Server/DC and Cloud.
Xray server/DC
As the API call is made on Jira server/DC REST API, we need to use its authentication mechanisms (e.g. basic authentication or Personal Access Tokens).
What will change between each type of Test is the payload, so we are providing one example for each type.
Manual Test
After making the request, the Test will be created and the response will provide the id in the Jira side that you can use to access it.
In Jira you can check the Test created.
Generic
After making the request, the Test will be created and the response will provide the id in the Jira side that you can use to access it.
In Jira you can check the Test created.
Cucumber
After making the request, the Test will be created and the response will provide the id in the Jira side that you can use to access it.
In Jira you can check the Test created.
Please find more information in the documentation.
Xray Cloud
As the API call is made on GraphQL API of Xray Cloud, so the requests made to Xray's GraphQL API must also be authenticated using the same end point for REST API authentication.
The authentication process uses a Client Id and a Client Secret, both of which are based on an API Key created for a specific user in Xray Global Settings: API Keys global settings.
Thus, the first step for you is to obtain the token based on the Client Id and Client Secret of your assigned API Key. You can then use any GraphQL or REST API end points.
What will change between each type of Test is the payload, so we are providing one example for each type.
Manual Test
The request for the GraphQL API is made using the createTest mutation as we can see below:
After making the request, the Test will be created and the response will provide the id in the Jira side that you can use to access it.
In Jira you can check the Test created.
Generic Test
The request for the GraphQL API is made using the createTest mutation as we can see below:
After making the request, the Test will be created and the response will provide the id in the Jira side that you can use to access it.
In Jira you can check the Test created.
Cucumber Test
The request for the GraphQL API is made using the createTest mutation as we can see below:
After making the request, the Test will be created and the response will provide the id in the Jira side that you can use to access it.
In Jira you can check the Test created.
Please find more information in the documentation.
Scenario2: Update Test(s) in Xray
Once you have used the first scenario to create Tests in Xray (linked to tests of the external tool), you need to assure that they are always showing the same information, for each time a change occurs in the external tool (edition of the test) you should update the Test in Xray side.
Full synchronisation is hard to achieve, so after creation we suggest to update the minimal information, such as description or summary. We trust that the details will be safe in the external tool.
In this case we're assuming:
- Test exists in Xray and another Test object exists in the external tool (linked to this one)
And we want to...
- Update the “same” test(s) in Xray because something changed in the Test (edited via the external tool)
Xray server/DC
As the API call is made on Jira server/DC REST API, we need to use its authentication mechanisms (e.g. basic authentication or Personal Access Tokens).
After making the request, the Test issue will have the our field (i.e. description) with a link to the test on the external tool.
Xray Cloud
As the API call is made on Jira Cloud REST API, we need to use a Jira Cloud API token created manually beforehand.
After making the request, the Test issue will have the our field (i.e. "description") with a link to the test on the external tool.
Tips
Use wiki markup to not only to format text but also to provide additional information or access to it
The Description field support Jira wiki markup, so you can use formatting to insert. a link for instance.
There can be some subtle differences between Jira server/DC and Jira Cloud, so we advise you to try it out on both deployment types.
What can it be used for?
Some ideas:
- On the Description field,
- provide a link to the external tool, where users can see the correspondent Test in the external tool.
- provide some table, or some bullets, with some additional info about the context of the batch execution and that thus apply to all results (i.e. Test Runs)
- embed a image (e.g. a chart); image must be stored in some accessible URL
Use labels
When creating a new Test you have the ability to associate a label to it.
What can it be used for?
Some ideas:
- This will make it possible to perform analysis over the origin of the Tests or to easily identify the ones that were created via automation to apply some action over those.
- This will enable you to filter those Tests using Jira queries.
Implementation Checklist
For this purpose, please make sure your tool provides these:
- Xray and Jira configuration
- Xray server/DC or Xray Cloud ? (which implicitly will define if Jira server/DC or Jira Cloud are being used)
- Server/DC specific settings
- Use Jira username/password or Personal Access Token?
- Jira username
- Jira password
- Personal Access Token
- Cloud specific settings
- Jira username
- Jira API Token
- On each test on the tool, associate it to an existing Xray Test issue
- specify Test issue key
- Discover the custom fields ids of the entities being used
Recommendations, tips, and concerns
General integration tips
- Provide links from your tool to Xray and the other way around. If facilitates navigation and access to information; we don't need to duplicate information in each tool.
- Example: if you're using an external tool to implement test automation and reports the results back to Xray, the Test Run details may contain a URL to the details on the external tool. That link may appear also at the Test Execution level, if it applies to all the tests run in that batch. On the external tool, a link could be provided so users can jump to Xray to see either the Test Execution or the details of a specific Test Run.
- Jira instances are highly customizable. This means that Jira administrators may define some rules to make certain custom fields mandatory on certain issue types, such as on Test or Test Executions, which will impact certain API calls that create Jira issues (e.g. importing results)
- In this case, the "multipart" endpoints for importing results should be used as they allow us to specify fields for the Test Execution, and also for the Tests, that may be created.
- Avoid performing many calls to achieve a certain flow
Xray Server/DC tips
- Support basic authentication, using Jira username and password, but also support Personal Access Tokens, a recent feature that may be better suited for integration purposes
Xray Cloud tips
- Authenticate once to obtain a token and use that token in all following requests; Xray Cloud tokens are valid for 1 day
- Xray Cloud has a rate limit of 60 requests/minute. Please don't exceed this limit or else you'll receive a HTTP 429 status error code; in that case, the "Retry-After" HTTP header contains the number of seconds to wait until a new request can be made
Topics to cover/add in the future
- Data-driven testing and datasets
Useful resources
- Xray Postman Collections (Postman collections showcasing usage of APIs both for Xray server/DC and Xray Cloud, including REST and GraphQL examples)
- RestMan (a Chrome extension very useful to try out REST API call)
- Postman (API client with good support for REST APIs)
- Insomnia (API client that provides good support for GraphQL)
References
- Xray server/DC
- Jira server/DC REST API
- Xray server/DC REST API
- Xray usage tips for improving performance (see integration and REST API sections)
- Xray Cloud