Control over new version and un-do/re-do of changes made
When editing a test case, I don't always want a new version created. It would be nice to have a way to un-do or re-do changes before committing a new version to the repository. (it would be helpful to be able to un-do an action such as making changes to or deleting a test step)Don't clone "Call to Test" steps when cloning a Test Case
I love the "Call to Test" feature when writing test steps and this was a big selling point for us. However I recently noticed that if I clone a test cast that uses "Call to Test", that the called tests are also being cloned. This is exactly what I don't want to happen. I can't imaging that this is the designed behavior. When I reached out to customer service they said this was the intended behavior. I hate this and for us it defeats the purpose of the "Call to Test" feature. We have a some basic app functionality for performing operations like environmental setup and post-action verifications that need to be executed for many tests, and sometimes these actions change. Instead of writing the discrete steps for dozens or hundreds of Test Cases, we want to use "Call to Test". Then if the action changes we only have to update that Called test. If the "Call to Test" test is cloned when I clone a Test Case, I now have to edit the cloned Test Case to point to the originally intended Called test, and delete the clone of the Called test. Otherwise I will have unwanted copies of the Called test which defeats the power of having this; creates a maintenance nightmare; and destroys the tractability I'm looking for to track how often the Called test is run and it's results. I'm sure there are users that like the way this feature works, but I'd like to have an option to not clone the "Call to Test" steps and instead just clone the step to point to the same "Called to Test" test as with the original Test Case.Add feature to land in the correct page of test cases if it goes beyond three level
Accessing the direct Test Execution link in Zephyr doesn't navigate to the correct page. Instead, it redirects to the root folder or project homepage. It is landing to the correct page till three levels from root. in the fourth level if we open a different tab it is going back to root. This is causing trouble for validators where the test cases lie beyond four level.Ability to use tab to move within test steps
As a user, I need an easy and accessible way to navigate the screen while creating or editing a test case. Currently, you cannot use tab to move to the next text box when creating or updating a test case. It is also very difficult to click to the next test step without it creating a second step below the step you're working on.Folder copy from test repository is not retaining the testcase order - CTSD-3106
Hi Team, Folder copy from test repository is not retaining the testcase order, Instead reordering based on testcase id. for example in a folder ACB we have 3 testcases with names one(Order 1), Two(Order2) and Three(Order 3). Then I copied the “abc” folder to "def” folder, now the order is changing based on testcase id.Ability to reference a test case within another test case
When creating and executing test cases, having the ability to reference a test case within another test case step/detail will save time, effort, and confusion for users. Being able to just reference an existing test case, instead of re-writing it, will increase efficiency as the user creating the test case and the user who are executing the test case (this allows users to either navigate to the reference test case to follow, or skip it because they already have that knowledge/know the steps.Ability to reorder folders and entities.
Creating folder hierarchies and organizing test sets/cases/requirements etc is a large part of keeping our repos clean and legible. Without the ability to reorder these folders and entities we are forced to use alphabetical prefix that make reading folders more difficult at a glance, or be stuck with disorganized cases (or manually adding them to sets one by one in the right order for potentially thousands of cases) because a new test case was added that is showing in last place when it should come after the 50th case for example. Added an example below with names for visibility, Test Case 1 and 2 were initially created, and then a new feature or change order came in that added a new case (1.5). In our ordering, 1.5 comes before 2 can be run but because it was created later it's automatically sent to the bottom (sorted by ID). Again our option becomes to prefix them with an ordering of IDs and sort by name which is much more tedious and harder to manage. It becomes especially rough when it comes in 50-100-200+ test cases later, or finding it afterwards to create execution sets.Add an four eye concept for test case deleting
To make it more secure that one or more test cases will be deleted erroneously it would be good to have the possibility to configure an four eye principe for deleting test cases. If user A decide to delete a test case user B get a notification that user A want to delete one or more TC's. Only when both users confirm the deletion will be executed.