Page History
...
Large organizations or organizations with huge amounts of data and/or having many users should consider Jira Data Center, which increases performance and improves throughput on higher concurrency usage scenarios; it also provides high-availability for critical scenarios.
There are some general administration related tips that you may want to consider; there are many, so please consider these just as a guidance.
- moderate the usage of custom fields
- ??
Process
- moderate workflow usage, in terms of their complexity (i.e. number of workflow steps)
- evaluate the plugins/apps you need as some may impact performance
Process
" "Unified" development process: define a process that can be applied to all teams in the way how 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, better; this is the key to ensure an optimal usage and have the 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;. 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.
Specification
Avoid having many (>>10) sub-requirements (>100) per requirement (e.g. Stories per Epic) as it can impact the calculation of their statuses- normally it is a signal that the requirement needs to be further decomposed. Besides hardening analysis and its management, it will also require additional resources during computation of its status upon changes in any of the related sub-requirements, that in turn is affected by the status of the related Tests.
Requirements being covered by many (>>20>>100) Tests- normally it is a signal that the requirement needs to be further decomposed. Besides hardening analysis and its management, it will also require additional resources during computation of its status, that in turn is affected by the status of the related Tests.
...
don't create dozens or hundreds of Test Environments; don't try to do data-driven testing using test environments- it It will impact the calculations that need to be done and the size of Lucene index
Entities
Tests
- .
Test Environments should be used as means to identify different testing stages, different browser vendores, different mobile devices; the number of environments should be well-defined and limited.
- .
Entities
Tests
- Don't add many custom fields to Tests as it will add some additional overhead to Jira.
- Don't add many custom fields to Tests as it will add some additional overhead to Jira.
- We recommend up to 5 linked Tests per each requirement; ideally a Test should be focused on the validation of one requirement.
This recommendation helps improve performance both on the TestRunStatus and Requirement Status calculations and also when loading the issue screens and reports.
- Promote reusability and avoid cloning Test cases, if they’re the same. A Test can be reused multiple times and can be used to cover more than one requirement (if really needed), no matter in which project it is located.
...
- Creating a Test Plan from within some Test Repository folder that has many Tests and sub-folders can take some time, if you choose to replicate the folder structure into the destination Test Plan Board. However, this is temporary.
- Avoid many folders shown at the same time as it will impact browser performance at some time. You can do this by limiting of direct child folders you create at a given parent folder and by using the "Expand all" moderately. The amount of folders you have does not affect by itself your Jira backend performance though.
Test Executions
- Reuse existing Test Executions (and related Test Runs), if possible, Clean-up old, unneeded executions related data, to make calculations faster througout the application and thus make reports and some panels, for example, also faster
if you don't need historical data of interim builds, you may reuse an existing Test Execution and update the corresponding Test Runs. During CI, depending on the endpoint being used, you may specify a Test Execution issue key. In such case, Xray will overwrite the existing Test Runs information, or add new ones if the Test is not yet part of the Test Execution.
- Clean-up old, unneeded executions related data, to make calculations faster througout the application and thus make reports and some panels, for example, also faster
If your organization performs a high number of Test Executions (consequently creating also a high number of Test Runs) we recommend deleting old Test Executions issues from time to time. This recommendation applies to organizations that import many automated executions daily using the REST API.
The clean-up process must be scheduled for a low Jira usage period because when Test Executions are deleted, Xray will re-calculate TestRunStatus and Requirement Status. This might temporarily slow down the Jira instance depending on the amount of issues affected.
- Deleting Test Runs can affect the calculated and consolidated status of your Tests and of your requirements for all scopes (e.g. versions or Test Plans + Test Environments); please use carefully
If your organization performs a high number of Test Executions (consequently creating also a high number of Test Runs) we recommend deleting old Test Executions issues from time to time. This recommendation applies to organizations that import many automated executions daily using the REST API.
The clean-up process must be scheduled for a low Jira usage period because when Test Executions are deleted, Xray will re-calculate TestRunStatus and Requirement Status. This might temporarily slow down the Jira instance depending on the amount of issues affected.
- Deleting Test Runs can affect the calculated and consolidated status of your Tests and of your requirements for all scopes (e.g. versions or Test Plans + Test Environments); please use carefully
- Although there isn’t an hard limit, we recommend having no more than 2000 Tests in a given Test Execution mostly to ease their management. This limit may be easily superseded depending on Jira instance deployment configuration. Although there isn’t an hard limit, we recommend having no more than 2000 Tests in a given Test Execution mostly to ease their management. This limit may be easily superseded depending on Jira instance deployment configuration.
Test Plans
- Xray provides a setting ("Max number of Tests per Test Plan") where you may define a soft limit for the number of Tests within Test Plans. Although you may adjust this value, we recommend having no more than 2000 Tests in a given Test Plan:
- to ease their management;
- and to make it more performant and lighter.
Note that a Test Plan aggregates and consolidates the results of the related Test Executions and Tests, thus the overall number of Test Runs you'll have can add some overhead to the calculation of the consolidated results.
...
- limit may be easily superseded depending on Jira instance deployment configuration.
Note that a Test Plan aggregates and consolidates the results of the related Test Executions and Tests, thus the overall number of Test Runs you'll have can add some overhead to the calculation of the consolidated results.
Test Plan Board
- Avoid many folders shown at the same time as it will impact browser performance at some time. You can do this by limiting of direct child folders you create at a given parent folder and by using the "Expand all" moderately. The amount of folders you have does not affect by itself your Jira backend performance though.
- Using the Test Plan Board as means to do operations over certain Tests of the Test Plan (e.g. schedule Test Executions for them) and to track results can be more efficient than using the Test Plan issue screen. Although the previous two are not equivalent, the Board provides essentialy the same operations while being lighter most of the times as it not shows all the information you can see in the Test Plan issue screen. Avoid many folders shown at the same time as it will impact browser performance at some time. You can do this by limiting of direct child folders you create at a given parent folder and by using the "Expand all" moderately. The amount of folders you have does not affect by itself your Jira backend performance thoughlighter most of the times as it not shows all the information you can see in the Test Plan issue screen.
Integrations
Automation & Continuous Integration
- Upload only relevant test results (e.g. don’t upload unit test results); choose properly what testing results you want to track within Xray
- Choose properly the upload frequency
- aggregate Aggregate relevant results in some job run periodically (e.g. hourly, daily) and submit those
- Don’t mix the CI tool with TM tool
- Leave the highly detailed execution info on the CI tool
...
- Xray provides some specific custom fields that calculate their values on the fly. This means that you should have that in mind, specially if you're including them in tables/issue listings/gadgets.
Test Execution Defects
test set status
tests count
Reports and Gadgets
- One way of doing reporting is by using gadgets. Gadgets are great to share information between team members and even between different teams; however, if not use carefully, they can degrade JIRA performance if all users have the same report on their dashboard as they will probably generate multiple requests once users access the dashboard. Thus, use carefully most intensive gadgets such as the "Historical Daily Requirement Coverage" and the "Tests Evolution" gadget and others that do aggregations (e.g. "Test Runs Summary" gadget). Gadgets that just "list" entities should not affect performance significatively.
- Limit the target issues for the reports/gadget CONF, e.g. generate the Overall Requirement Coverage (report/gadget) just for issues that you really need and not all Jira requirements or projects.
...
- quais outros settings podem ter mais impacto na performance?
- estado calcula com base no testset; cuidado ao mudar
...
- Don't use complex workflows for Xray entities as it will harden their usage; if the workflows have many steps then it will impact overall Jira performance
Reindex???
?? avaliar questao de tirar searcher ao Test Execution Defects
...