Page History

...

Although Xray is quite flexible and supports many different project organization scenarios, we recommend you to have your testing related artifacts together with other project related ones, such as requirements/user stories, bugs, tasks, etc. This approach provides a self-contained project, it's easier to understand and manage and, best of all, promotes team collaboration.

...

• Clone Tests and use the "data" column to put the values for the inputs of each partition/class
• If doing Equivalence Class Partitioning, don't specify exact values for the class, to have some randomness; if later on you find a bug, you may create a Test case with the exact value to verify the fix

Few Tests (or few testing) per requirement

A requirement covered by few test cases may be a symptom of lacking test cases, testing only the successful path.

• Create more Tests using white and black-box testing related techniques

...

Promote reusability and avoid cloning Tests specifications

If Tests are exactly the same, in theory there should be no need to have clones.

Whenever talking about clones, we may be talking about explicit clones (i.e. cloning the whole Test issue, with all its steps) or implicit/embedded clones (i.e. where the steps of an existing Test are used in another more high-level Test case). 

If you are thinking on using Tests as steps in other more high-level Test case you should consider modular tests and not using implicit/embedded clones.

Depending on the purpose you want to achieve you should use the best suited approach, so if you wish toIn general, users may clone Tests for different purposes:

• Perform the same Test but against different data
  • Use test parameterization , when it's available; until then, there are different "workaround"/interim approaches that can be followed, where the first is probably the best one:
  • Clone Test and use the "data" column to put the values for the different parameters. This is valid if you don't need to filter later on by these parameters, otherwise the parameters can be persisted as specific custom fields on the Test issue, and thus easily be queriable or reported against. Some caution should be taken with the later, in order to avoid huge amounts of custom fields which will burden management and also affect performance of Jira instance. This approach allows to track the coverage per each different data values combination.
  Specify parameters at the moment of execution. Since a Test Execution can only contain a Test once (i.e. it can only contain 1 Test Run of a given Test case), this would mean creating as many Test Executions as the possible combinations of input values. Parameters and their values could be defined as custom fields on the Test Execution; care should also be taken in order to avoid huge amounts of custom fieldsand datasets, this will allow the correct replacement of the parameters by data defined by the dataset. As you can see in the documentation you can define the dataset in different entities or scopes of your tests.
• Cover/test different requirements, of different projects; in this case projects may be somehow similar and may represent slight variations/conditions of the "main requirement"
  • You may use the same Test for this (probably the Test would reside in some common project); however, if you do so, then the Test result will affect related requirements in the same way (unless you change the Separation of Concerns setting). Instead, and because you're probably really talking about different requirements, the best is to have specifically designed Tests for each individual requirement
• E2E Test composed of steps, where these steps are essentially existing Test cases
  • In this case, if you have defined some Tests that can be used as modules in other Test steps, you should use modular tests to include other Tests as steps of a more high-level Test case. Make sure this will focus the Test in the feature you want to validate and not in the feature of the Tests you are including.
  • You can also
  E2E Test composed of steps, where these steps are essentially existing Test cases
  • In this case, the best is to design the E2E Test in such a way that its steps are more simple and validate only what is the purpose of the E2E Test itself (e.g. instead of having an E2E Test with all the steps of a login related Test case, the E2E Test can have just one step where the user is expected to login using given username/password)
• Tests having some common initial steps 
  • Abstract those common initial steps in reusable Pre-Conditions linked with all those Tests

...