What is the right process for different xray issues in a project with user stories and bugs?

[h kay]

Hi,

I would like to create an xray requirement coverage project that is made up of user stories and bugs being developed and fixed over x amount of sprints with a final phase of regression testing. We are planning to use xray as the test management tool. I have seen there are various ways to organise test cases however I have not been able to pin down any guidance on how to use organise a testing process for user stories and bugs.

Any reading I have done for test plans implies that test plans should be used as an overall plan to provide a status of all test cases that test all user stories for a release.
1. How can I represent the testing tasks (i.e. what testing is being done/has been done) that sit under each user story / bug in a release? What issues can I use?
2. Should a test plan be used to cover all test cases for a release or can it be used per user story in a release?
3. Based on the answer of 2), how should test executions be used. To track the progress of a user story can a user story have more than one test execution associated with it? e.g. test execution is run, one test in it failed so another test execution is needed.
Is it ok to place these directly under the user story to know how long a tester took to execute a set of tests and how many were executions were needed?
Any guidance on the above would be much appreciated as I can see xray is a great tool with lots of potential.

Thank you kindly

[José Domingues [Xray] · Accepted solution]

Hi, @h kay

First, we would like to state that although we do have some recommended ways of structuring Xray projects, the way every client sets up his projects is completely up to each own, as we do not know how your company's preferred work method is. That being said:

1. To represent a group of tests, you can use a Test Set, allowing you a faster way of associating the tests to other issue types. For a "testing task", you can also use the Test Plan, as it provides a unique point of view over the associated tests and test executions.
2. Again, this is not up to us to decide. We have seen both approaches working on several different clients. It all depends on how you keep track of your work and how you want it to be structured. Do you prefer to have less, more "filled" Test Plans to analyze and compare? Then you should use them "to cover all test cases for a release". Or are you looking for a way to be able to compare test results within the same release? Then, you can use them "per user story in a release".
3. First, addressing this specific question can a user story have more than one test execution associated with it?. Yes, it can.
   Second, addressing this example e.g. test execution is run, one test in it failed so another test execution is needed.. This is the correct process if you wish to retain historical data of your executions because you can rerun the same Test Execution associated with the Story. However, by doing so, you'll lose the status data from the previous execution.
   Finally, going for the last question Is it ok to place these directly under the user story to know how long a tester took to execute a set of tests and how many were executions were needed?. Yes, it is ok to do this if you see that this is the best way for your company to analyze the Test Executions.

Best Regards, 

Team Xray 

[h kay]

Thank you for your reply. It has been most useful and answers my questions.

It's good to get thoughts from people with experience on how issue types are used.