Sprint/Agile suggestions for X-Ray plugin config?

[Justin Leader [HyperVelocity]]

Hey all,

X-Ray is great, but I'm running into some conceptual problems when setting it up to interact with JIRA Agile Sprints. I have a few questions:

• During a sprint, when the QA staff creates the tests, I'd rather they don't add to the scope of the sprint, as they will as parent issues...
• The tests shouldn't ever really close, because they may be used again; it's the test executions that need to close...

Any thoughts on how to make this as elegant when integrated into a Scrum team?

Thanks!

[Marisa Hager]

Well, this is 4 years late, but I had a similar question and this article really helped me understand the different xray types in the context of sprints and releases:  

"Tests, Pre-Conditions and Test Sets are reusable entities; thus, in typical scenarios, they do not belong to the scope of a release or of a sprint.

On the other hand, Test Executions, Sub-Test Executions and Test Plans represent work targeted for a given release and/or a given sprint. Thus, they can be tracked as any other issue that needs to be handled in the scope of your release/sprint. If you have these issues assigned to some release through the FixVersion/s field, then they will appear in the summary information of the Releases project page as shown ahead."

Reference article here: https://confluence.xpand-it.com/display/public/XRAY/Using+Xray+in+an+Agile+context#UsingXrayinanAgilecontext-Process

[Deleted user]

Hi Justin,

Did you ever get to the bottom of this? I'm currently investigating test tooling options for an Agile team and, without having implemented X-Ray yet, have the following model in my head:

• Test Executions are defined in parallel with the stories during sprint planning
• Time estimates are assigned to the Test Execution in sprint planning to account for the time that will be spent preparing and executing the tests for that story
• During the sprint, QA prepares new tests and/or assigns existing tests to the test execution created during sprint planning. The time spent doing this is logged against the test execution
• Once all tests are passed and the story is complete, the Test Execution dies with the sprint
• Tests created for previous executions are available for reuse in future sprints with new stories

I struggled conceptually due to having previously worked with Zephyr, in which executions only exist as (second class, conceptual) sub-types of Tests.

Would appreciate thoughts before we implement this strategy!

Kind regards,