Page History
...
- major
- highest
- high
- medium
- low
- lowest
A large number of Xray issues and Jira's performance impact
The number of issues is usually an indicator of the size of a Jira instance and a possible culprit for performance degradation. Yet, there are so many other elements that can affect the scale of a JIRA instance, such as the number of users, workloads, etc.
Xray uses issue types to map the majority of its entities. Tests, Preconditions, Test Sets, Test Plans, and Test Executions are all issues in Jira. This means that having many Xray issues can also affect Jira's overall performance.
Nevertheless, the Xray issue types can affect Jira's performance in different ways. We expect Tests, Preconditions and Test Sets to have a lesser impact than Test Plans or Test Executions.
If customers are importing automated execution results into Xray daily (for several projects and teams), the number Test Execution issues will grow significantly over a relatively short period.
A large number of Test Executions can affect Xray test status and coverage calculations, thus contributing to Jira's overall performance.
Test Plans aggregate and consolidate the results of the related Test Executions and Tests. Therefore, the overall number of Test Runs can add some overhead to the calculation of the consolidated results.
Below we provide some tips on how to scale Xray.
Jira specifics
Xray is built on top of Atlassian's Jira, therefore it is mostly dependant on the architecture and technologies followed by Jira itself.
Atlassian provides some performance tips related to scaling, that this also applies to Xray.
Large organizations or organizations with huge amounts of data and/or many users should consider Jira Data Center, which increases performance and improves throughout higher concurrency usage scenarios; it also provides high-availability for critical scenarios.
There are some general Jira administration related tips that you may want to consider; there are many, so please consider these just as a starting point:
...
...
Jira specifics
Xray is built on top of Atlassian's Jira, therefore it is mostly dependant on the architecture and technologies followed by Jira itself.
Atlassian provides some performance tips related to scaling, that this also applies to Xray.
Large organizations or organizations with huge amounts of data and/or many users should consider Jira Data Center, which increases performance and improves throughout higher concurrency usage scenarios; it also provides high-availability for critical scenarios.
There are some general Jira administration related tips that you may want to consider; there are many, so please consider these just as a starting point:
- Moderate the usage of custom fields
- Moderate workflow usage, in terms of their complexity (i.e. the number of workflow steps);
- Evaluate the plugins/apps you need as some may impact performance.
Performance impact of a large number of Xray issues
The number of issues is usually an indicator of the size of a Jira instance and a possible culprit for performance degradation. Yet, there are so many other elements that can affect the scale of a JIRA instance, such as the number of users, workloads, etc.
Xray uses issue types to map the majority of its entities. Tests, Preconditions, Test Sets, Test Plans, and Test Executions are all issues in Jira. This means that having many Xray issues can also affect Jira's overall performance.
Nevertheless, the Xray issue types can affect Jira's performance in different ways. We expect Tests, Preconditions and Test Sets to have a lesser impact than Test Plans or Test Executions.
If customers are importing automated execution results into Xray daily (for several projects and teams), the number Test Execution issues will grow significantly over a relatively short period.
A large number of Test Executions can affect Xray test status and coverage calculations, thus contributing to Jira's overall performance.
Test Plans aggregate and consolidate the results of the related Test Executions and Tests. Therefore, the overall number of Test Runs can add some overhead to the calculation of the consolidated results.
Below we provide some tips on how to scale Xray
...
.
Process
- "Unified" development process: define a process that can be applied to all teams in a way to manage the STLC. Every team is different and has its own needs, therefore your process should not be too strict but it should provide some guidance on how development life cycle should be addressed, covering requirement management, bug management and test management. Having teams working completely in different ways hardens communication and leads to unproper and unoptimized tool usage. If you have a well-defined process that can be used organization-wide, this is better, because this is the key to ensure optimal usage and best performance.
- Are you adopting Agile and Scrum? Check out Using Xray in an Agile context for tips on how you can take advantage of Xray in such scenarios; the Agile software development page provides high-level overview of Agile and Agile Testing and besides background information on them, it will also provide some useful tips so your team can be more Agile and avoid doing things that are unnecessary.
- Each Xray entity has a purpose/fit that you should try to take advantage of. You're not obliged to use all of them; you can even choose to use some over other ones. In order to have an optimum usage of Xray, we would recommend understanding, first of all, the purpose of each entity.
Expand Entity / Issue Type
Purpose
Test
For making the specification of some test; a test case template.
Pre-Condition
For abstracting some initial condition that one or more tests must assure; reusable, i.e. linked to one or more test cases.
Test Set
For creating lists of test cases, so you can easily pick those test cases afterwards in case you need them.
Test Execution
For scheduling an execution of a bunch of test cases in some version&revision of the SUT.
A Test Execution contains several Test Runs, one per each ”linked” test case.
Sub Test Execution
Similar to a Test Execution; the difference between them is that the Sub-Test Execution is a sub-task and can be created within the context of a requirement.
Creating a Test Execution as a sub-task of the requirement issue provides you with the ability to track executions in the Agile board.
Test Plan
For grouping multiple Test Executions and presenting a consolidated overview of them; tracks the results of some Tests in some version/sprint of the SUT.
Test Run
An instance of a Test in the context of some Test Execution; contains a copy of the original Test specification along with the recorded results. It’s not an issue type.
Test Repository
A per project hierarchical organization of Test cases using folders; an alternate approach to Test Sets for organizing test cases.
Test Plan Board
A per Test Plan hierarchical organization of Test cases, at the planning phase, using folders.
It is used for...
- grouping, organizing the tests in the context of the Test Plan and to easily track the results of certain Tests grouped in some folder;
- easily changing the ranking of the Tests, to create Test Executions for them afterwards.
...