Sprint/Agile suggestions for X-Ray plugin config?

Justin Leader [HyperVelocity] September 19, 2015

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!

 

2 answers

0 votes
Marisa Hager November 19, 2019

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

0 votes
Deleted user June 28, 2016

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,

 

Suggest an answer

Log in or Sign up to answer