...

There are some general administration related tips that you may want to consider; there are many, so please consider these just as a guidancestarting point.

1. moderate Moderate the usage of custom fields
   

   1. Managing custom fields in JIRA effectively

   2. Optimizing custom fields
2. moderate Moderate workflow usage, in terms of their complexity (i.e. number of workflow steps)
3. evaluate Evaluate the plugins/apps you need as some may impact performance

...

1.  Avoid having many sub-requirements (>100) per requirement (e.g. Stories per Epic) as it can impact the calculation of their statuses
   1. 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.
2.  Requirements being covered by many (>>100) Tests
   1. 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.

...

1.  Instead of creating one Test Plan for your release, you may create multiple Test Plans to track different Tests (e.g. manual vs automated); this may be useful if you want to have clear visibility of how certain groups of Tests are progressing and if their execution lifecycle is different from other ones. It will also make your Test Plans considerable lighter.
2.  If adopting Scrum, create Test Plans per Sprint, to track the testing being done in the scope of your Sprint; manage them as artifacts of your Sprint and add them to your Scrum boards so everyone sees their progress. Per each Sprint you may have more than one Test Plan; check out some possible usage patterns here. 

Execution

1.  don Don't create dozens or hundreds of Test Environments; don't try to do data-driven testing using test environments
   • It will impact the calculations that need to be done and the size of Lucene index.
     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.

...

1.  Although there isn’t an hard limit, we recommend having no more than 2000 Tests in a given Test Set mostly to ease their management. This limit may be easily superseded depending on Jira instance deployment configuration.

...

1.  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

   1. 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.

   2. 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 proceed carefully
2.  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.

...

1.  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:
   1. to ease their management;
   2. and to make it more performant and lighter.
   This 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.

...

1.   Using unoptimized JQL queries can degrade performance substantially
   1. most times this happens because users don't understand how JQL works first of all; JQL is not like SQL (see Understanding JQL Performance). Thus, filtering issues by project by adding the "project = <xxx>" clause is not the same as specifying the project as argument to the subsequent JQL function.
      
      1. Example: 

         1. Use

            issue in requirements('OK','CALC')

            ...instead of ...

            project = 'CALC' and issue in requirements('OK')
            
            

2.  Some JQL functions, such as the ones dealing with requirement coverage, may be more intensive than other ones, since Xray may have to, for example, load all the related Test Runs in order to obtain relevant data. The following JQL 

   1. testPlanTests() - whenever by tests in a given status; the current workaround is to search using the "TestRunStatus" custom field. 

      Note
      title Please note
      When searching for Tests with a certain status inside a Test Plan, we recommend you to use the custom field search instead. Xray has created a new way of searching with big improvements when filtering by test status, using the Custom Fields: (3) issuetype = Test and TestRunStatus = "DEMO-10 - TODO" (4) issuetype = Test and TestRunStatus = "DEMO-10 - TODO environment:IOS"

   2. requirements() - whenever filtering by by dates
   3. testExecutionTests() (Diamantino Campos diamantino  tem duvidas?)  - whenever filtering by tests/requirements in a given status; it will depend on the amount of Tests you have on the Test Execution
   4. parentRequirements() (Diamantino Campos diamantino  tem duvidas?)  - depending on the amount of requirements and sub-requirements you have, it can take a while to complete and require some resources
   5. Diamantino Campos ,

...

1. 1. any other Jql function?

Xray calculated custom fields

...

1.  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.
2.  Limit the target issues for the reports/gadgets CONF, e.g. generate the Overall Requirement Coverage (report/gadget) just for issues that you really need and not all Jira requirements or projects.

Dashboards

1. Image Added Choose properly the filters you use for each gadget, in order to restrict the amount of issues that will be processed
2. Image Added Don't use low (i.e. intensive) refresh times as they will add some overhead to the Jira instance
3. Image Added Use shareable dashboards to have the high-level overview and the things that matter but avoid creating highly complex dashboards
4. Image Added Try
5. Use dashboards to have the high-level overview and the things that matter
6. Avoid creating highly complex dashboards or dashboards
7. Try to normalize the dashboards and make them like a standard organization wid
   1. facilitates communication
   2. avoids “wrong” usage
8. Choose properly the filters you use for each gadget, in order to restrict the amount of issues that will be processed
9. refresh timeswide; it will facilitate communication and avoid “wrong”/unoptimized usage

Custom Reports

1.  If possible, use eazyBI for making custom table/chart based reports with drill-down capabilities; it is highly flexible and works in its own database, thus not impacting Jira unless the database is hosted in the same instance of Jira server/database
2.  If using the Xporter app to build custom PDF, Word or Excel based reports, then please see Xporter specific recommendations.

...

Xray comes with default settings that are ok for most organizations. Nevertheless, have a look at the different settings; it’s an opportunity to know the product better and for you to think on ways to fine tune it later.

1.  Review the settings "Max Test Runs for bulk operations", "Max number of requirements per report or gadget results", "Max number of Tests per Test Plan", "Max results per request" in the the Miscellaneous administration settings. The default value values should be ok.
   
2. Image Modified Using  Using the requirement coverage strategy "Use versioned Test Sets for Requirement Coverage" will require additional computational resources on daily usage; therefore, the default "Use versioned Test Executions for Requirement Coverage" strategy is the recommend one. Learn more in Requirements Coverage. If you change this setting, then it can take a while until all statuses are re-calculated depending on your instance dimension.

Your own custom fields

1.  Beware with calculated custom fields implemented using some customization app (e.g. Jira Misc Custom Fields, ScriptRunner, etc) as they will be calculated each time they're accessed and they can impact things such as:
   • indexing time
   • REST API calls (e.g. whenever searching issues)
   • on listings (e.g. on Issues search page, Filters Results gadget, Xray tabular sections) if they're included as columns .
2.  Adding a lot of custom fields on Jira will add some overhead on performance; therefore, Atlassian itself recommends a responsible usage of custom fields.

...

?? avaliar questao de tirar searcher ao Test Execution Defects

Other operations

1. Image Added Avoid bulk cloning

...

1. Test plans or Test Executions using some specific apps for that purpose; cloning multiple issues at the same time can add some overhead to Jira as these can affect the 

Data Center Tips

1.  Review Atlassian's best practices for Data Center and the Node sizing overview for Atlassian Data Center article
2.  Configure your load balancer properly to use dedicated nodes for REST API calls, which can reduce impact on other application nodes
3. Integration with other apps
   1.  S Please see eazyBI's Data Center related recommendations here

...