Zephyr test issues appearing "issues to do" in the release

Bob_Gehrlein

I'm new to Zephyr and am trying to understand the intent on how to use it for our project.  I've created test issues and gave them fix versions and components to organize them.  Also noticed them appear in the backlog.  I updated the filter to not include them in the backlog, but they still appear in the Releases as "issues to do".  From other posts I've read, test issues should not be closed because they are intended to be reusable.  I don't really want tests to appear in the release notes, but that is what happens when they have fix versions assigned.

Am I missing something?  Is there a better way to manage/organize this?  The Test Cycles are simple Ad Hoc cycles for the version.  Not using any test work flows, as I'm still learning the basics before setting up a more formal process.   Thanks!

Naveen K S

I would suggest not to add the fix version to your test cases and rather manage them differently since test cases are defined at a project level and ideally the same test cases will get used for all releases and you keep adding to this list, but for every release the outcome of the test case might be different this is where Zephyr introduces a concept called test executions which are more materialized view of the test cases but they are specific to a cycle.

The easiest way to doing this would be to separate your development work tracking in Jira to tracking the test cases. For development you would do it the normal way of adding them to the backlog and each artifact also being part of a sprint and eventually a release, but test cases are supposed to have a different lifecycle and work slightly different.

The general hierarchy is Release -> Cycle - > Folder->Test Execution (You can have test executions at the cycle level as well)

 

Before we start looking into the test lifecycle let’s get familiar with some of the concepts that Zephyr uses so that we understand their intended usage.

1. Test cycle – Logical grouping of all test cases so that they can be executed as a groupEx – Generally there are/can be multiple cycles under a release (regression, iteration 1, iteration N)

2. Test Folder – Logical grouping under a cycle to better align the test cases by folder for ex generally test cases belonging to various/different components can be part of different folders and they can be grouped and executed per folder

3. Releases – These are the same releases that are in JIRA for a given product and cycles can be defined under these releases. You can have cycles defined per iteration so that we have visibility at a cycle level and this helps you to organize it for sprints or you can have cycles defined for an entire release and track it that way so its up to the  teams that  way they would want to do.

 

So if you use the cycle summary page it will give you a visibility to what releases are currently open and what cycles are present in each of these release. The cycles will also have a neat little stacked bar that will give you a visibility into what is the current status of the executions within the given cycle(#of passed vs failed tests).