Zephyr Scale: Same test cycles associated with multiple test plans.
For example, we have:
Test Plan Release 1.0
Test Plan Release 1.1
Both test plans include the same test cycles. When we run the associated test cycles, the result is updated in BOTH test plans.
What is the best way to set up Zephyr Scale?
What we've done is clone the test cycles for each release, but this doesn't seem practical.
The Version and/or Iteration fields in the Test Player might help. You could use those to specify for which release you are testing. You'd first execute a test for Release 1.0, then click "Start a new test execution", change the release value, and execute that test. The test cycle also has the same fields but am not sure if that's what you're looking for in your scenario.
Thanks for the info. However, Test Plans don't appear to have any concept of "release version" so both Test Plans still show the same status versus Test Plan Release 1.0 showing status for Release 1.0 and Test Plan Release 1.1 showing status for Release 1.1.
Is there a way to associate a Test Plan with a "release version"?
I might be mistaken and have missed a feature but I don't think test plans are designed to work in that way. The status of a test plan is a text description as to the readiness of the test plan. The status won't update automatically based on the tests executed in the test plan's test cycles. To me, the test plan is only useful for logically grouping test cycles and referencing that test plan in a report (instead of having to reference multiple test cycles).
I think you need to use test cycles. They have readiness statuses as well but they also have execution statuses that automatically update based on the execution status of that cycle's test cases. So using your example you could have 2 test cycles for each release. Or you could have 1 (as per my example) - you run it once for v1.0, then change the release/iteration of the cycle to 1.1 and then you start a new execution of the tests for v1.1 - whichever best suits your needs.
A Test Plan should be able to show the correct execution status of the associated test cycles. What I am seeing is that if multiple Test Plans point to the same Test Cycle then both test plans will indicate that the Test Cycle is "Done" even though it wasn't run for that Test Plan.
I can easily clone a set of Test Cycles and have one set for Release 1 and one set for Release 1.1 and that will work, but it gets messy fast.
Another unfortunate thing is that the Test Plan just indicates "Done", not that it Passed, Failed, or other.
OK, now I've seen the screen print I can see what you're doing. I thought you were trying to use the Test Plans homepage to view execution statuses, which of course you can't. Personally, I don't rate using the Test Plan feature for anything other than organisation as I mentioned earlier - for me, it's only useful for reporting purposes. There are other, better ways to use ZS for what you need, and that is using the Test Cycles homepage. I've posted an example image below where you will see that there is much more detail available to you. With your current approach you have to drill into each Test Plan and go to the Traceability tab to get less information.
Your point about Test Plans using the same Test Cycles. It is working exactly as it should. You have linked a Test Cycle to two different Test Plans. The Test Plans are only different in name. There is no rules/logic defined (or available to us) for ZS to know that Test Plan 1.0 and Test Plan 1.1 are different. But, if you explore my suggestion about Test Cycles, this will fix that problem. You will have a Test Cycle Folder for Release 1.0 with it's unique Test Cycles (e.g. Feature 1, Feature 2, ...) and another Test Cycle Folder for Release 1.1 with it's unique Test Cycles (e.g. Feature 1, Feature 2, ...), and you will be able to execute and monitor those Test Cycles independently of each other.
Regarding the status of Done, this is also correct because a Pass/Fail status would be subject to conditions and there is currently no logic to define such a result. You can however create your own custom statuses (my example image above contains one: Blocked) which you can apply manually.
