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 ...
OK - lets get this straight.
I'm not trying to say this is wrong, but just that layers easily hide information, we all face the same problem with automated test cases, composition has to happen, and workflows or app wizards have to be able to change over time. And the danger is that when raising a defect, the defect gets tracked against multiple test cases that share that "shared-case" which the defect blocked. A test case has then actually become a validation of our ability to execute tests, not a way of talking about unique customer journeys. Turning test cases into work items that suit our process. Not to mention negative tests. Shared test steps, that makes sense, but any layering and perhaps multi-level nesting that can now happen, I mean can I then include a test in a test in a test in a test, and then the tester walks into the bar and orders a lizard. That will always create surprises.
OK, quick example time: Say you have 25 function tests that select a user, login, navigate to a specific menu page, and then test some function.
Rather than having 26 tests (including one test that just navigates to the page and validates the static content) repeat have all of the same steps to start out, and just add a different final couple of steps, 25 of the tests can just call the "select-user-login-navigate-to-menu" test and then test their specific function. Much easier maintenance. DRY (don't repeat yourself).
If the first test Fails ("select-user-login-navigate-to-menu") there should just be one defect link (critical defect), and the other 25 function tests should be marked as "Blocked", or "Untested" not "Failed".
Tester tries to walk into a bar, but the front door is barricaded. The rest of the bar tests don't really matter until that's fixed.
I sort of see your side Brian. Although the use of DRY is the classic defence, and I have to agree with you it makes perfect sense to use DRY as an argument. But when you understand the tests in a TCMS system are often just for making pretty reports, and simplify "testing-as-a-means-to-an-end" that some process and hygiene is needed. I'm not saying you are wrong Brian, I'm just saying we might be adding complexity to our testing tool data capture that we don't need, because it's an implicit detail.
What the OP has described is a "dependency" for a vast number of user journeys to be able to for-example "login". All that really means is that "login" is a critical test case, and the 25 tests that all share login as a step WILL be blocked. That is called a dependency and raises the priority of the test case, as a user I want to check that my grocery order is in fact booked for 7pm. Authenticating to the platform is implicit in this scenario, and is an artefact of system complexity, it's not a test case in the grocery order check scenario at all. We never see online shopping portals bragging about how easy it is to login to their platform, it's not a Unique selling point. Test cases coverage needs to be based around customer journeys, not the system complexity and architecture. For the "login " case, what if the login case requires also a 2FA token test, we now have 2 levels of indirection here, not to mention having a performant wifi connection to the cloud hosting. It's classic, all my automated tests suffer from this and I have to work hard to prevent automated test steps from becoming the only thing that matters. We have endless debates over whether the login is a "fixture", or part of the auto-test itself. I feel the pain too, so what I have done in my pipeline is to prioritise cover for common flows early in CI/CD and in release closedowns. Very little stops us adding a link to the test steps - unfortunately I don't think pasted links are clickable/converted to html. That might even be the original ask, clickable links/markdown?
A way of marking tests as blocked feels more useful than adding a reference to a test case which is "implicit" already, and may change at a future point too. Our SDLC process must aggressively prioritise removing bars to testing.