Page History
...
- moderate the usage of custom fields
- ??
...
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.
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
??
Entities
Requirements
??
Tests
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.
...
- 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 Lucene index
JQL
Xray provides dozens of JQL functions but you have to use them carefuly to make sure your instance is not affected. Please do train your users on JQL before "allowing" to use them throughout Jira.
- Using unoptimized JQL queries can degrade performance substantially
- 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.
- Example:
Use
issue in requirements('OK','CALC')
...instead of ...project = 'CALC' and issue in requirements('OK')
- Example:
- 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.
- 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 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
- requirements(), , testPlanTests() -
- testExecutionTests() - whenever filtering by tests/requirements in a given status; it will depend on the amount of Tests you have on the Test Execution
- parentRequirements() - depending on the amount of requirements and sub-requirements you have, it can take a while to complete and require some resources
...
Workflows on Xray entities
...
Don't use complex workflows
...
- for Xray entities as it will harden their usage
Settings
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.
...