To avoid creating unnecessary/redundant steps within a test case, is it reasonable to mention or reference another test case to avoid redundancy?
To decide whether you are going to reference other test cases to avoid writing the same sets of steps multiple times, you need to consider:
- the audience - If your test cases are written for unskilled manual testers who are expected to execute them without much if any thought, you may be better off with redundancy.
- usage - if testers are working with printouts, then you may be better with redundancy. If they're working with a tool and can simply click to open the referenced test case, you may be better referencing.
- test case management tool - some tools make cross-referencing test cases much easier than others, for instance Microsoft's Team Services/TFS test management has the concept of shared steps which can be linked in and will be listed in full during test execution.
- reporting needs - if you need to provide your customer with a copy of all test cases and your tool doesn't have the capacity to expand the linked test cases, you may need to list them all.
My preference is to avoid redundancy and repetition wherever possible, but there are circumstances where it may not be possible to have a more maintainable and DRY test case repository.
Generally No, particularly for automated testing.
Ideally each test case should have no external dependencies. When you find the need to reference information from another test case you should consider refactoring to remove the redundancy and include the steps as setup for the test in question.
Ideally you want to be able to run any test on its own and any set of tests in any order. Tests that have dependencies on other tests are a test code smell because we have learned over time that such dependencies lead to brittle fragile tests.
One option to address these issues is to ensure that you have a system for setup and teardown (often by using a test framework that does it for you). Within this it will be common for sets of tests to have common setup tasks that are defined once and then done for each case in that group. The data is NOT shared, it is still destroyed between each individual tests, the different being that the definition of the data is only done once. This is often done in a tree like fashion so that as you traverse down the branches the setup for each test will be combination of all the setups that are defined at the start of each branch that led you to the current test.
it depends on what your purpose is to avoid the redundancy.
if your work and other people's work are more convenient and efficient after this improve, then it is a good improve. but if the result is the opposite, then it is not a good improve.
based on my experience, to avoid the redundancy is just to save the time when you create those cases. but it does not have benefits when executing them. on the contrary, it is inconvenient for testers to execute.because testers need to go back to the referenced case to see the steps,then go back again to the executed case. this is more inconvenient when there are many cases especially with EXCEL tool. even you use the test management tools to do this, it is also inconvenient to switch back and forth when reading those cases.
and for automated cases,it depends on the framework. but i think it is more complete not to avoid the redundancy. if one case has dependencies on other cases, it is better to comment on the case in case that someone does not know and only wants to execute one test case not test suites.