Forum Discussion
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.
- MisterB2 years agoChampion Level 3
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.