Search, vote, comment and create ideas for Zephyr Scale improvements here. For more information on our review process, see here.
As a QA Manager
I want to lock test cycles in the test player
So that the data cannot be changed once it has been complete
Scope
Users will be able to lock a test cycle in the test player
Benefits
Better consistency
Avoids unwanted changes after a test cycle has been complete
Any suggestions? Please comment on this page :)
I agree that this should be basic functionality and is the only way to let other team members contribute to tests without giving everyone the ability to alter executed tests for audit purposes.
This feature is a must. We need the cycle results (and the test case version used in execution) locked against changes once test execution is over. This is a standard feature in different other products. See also https://community.smartbear.com/t5/Zephyr-Scale-formerly-TM4J/How-to-lock-a-test-cycle-mark-a-test-cycle-completed-and-no-more/m-p/216119
In strongly regulated environments like banking, insurance and financial services in general, this feature is absolutely essential. I'm wondering why it is not available right from the beginning?
Implementation should include role-based permissions for both locking and unlocking of test cycles which would satisfy regulatory requirements.
There are other test management solutions for Jira where this feature is easily configurable.
Our use case is that once a cycle is complete (or incomplete in some cases), people shouldnt be to accidently amend or add or change or manipulate the results so rather than archiving, the option to make it read-only would be better.
I can see this getting complicated as there might be cycles with custom statuses and the question would be what would constitute a completed test cycle - some may want to leave a cycle as failed/blocked and create a new cycle - but they may want that failed/blocked/incomplete cycle to not be tampered with and just become read-only. Well thats our case anyway - not sure about other customers.
Probably not, I imagine the person using this would be aware of the limitation anyway. I think people would generally only use this for very old test cycles?
To be honest, I don't know what the use case is here. Is it because test managers are scared that their testers would manipulate their executions? Maybe other people can comment here to say what they think.
Personally, I think I would opt for some 'Archive' feature if it hasn't been suggested already (out of scope of this idea) for cleanup.
Thanks Phil. This'll be likely added anyway. We're still gauging whether the "unlocking" is necessary.
Is this something that you would use if it were in place?
The only concern is the user (QA manager in this case) will have to be aware of that point. If there is definitely no way to go back and edit, I suggest putting an 'Are you sure?' kind of confirmation to inform them. That might improve the user experience.
Hi Phil, the behaviour might be more of a "complete" action for a test cycle. This would then end that cycle so that no changes can be made.
Do you have concerns about this?
Just to be clear, this does include unlocking as well?