Testing a service portal only makes sense once sign-in works. The “Create a service request” case therefore depends on “Sign in with valid credentials”. Starting with Zeta Test Management 6.0.7, these relationships can act as mandatory prerequisites in Windows and on the web.
Three rules for different needs
| Rule | Effect during a test run |
|---|---|
| Hint only | Shows the relationship without blocking result entry. |
| Must succeed | Requires a successful predecessor result. |
| Must not fail | Accepts successful and partially successful results. An untested predecessor is not enough. |
Existing relationships remain hints initially. Use a mandatory rule when the predecessor’s outcome is genuinely necessary for a meaningful test.
Set up the example
- In “Create a service request”, add the sign-in case as a dependency and choose Must succeed.
- Include both cases in the test plan. If you change the relationship in the library later, explicitly synchronize those changes into the plan.
- Create a test run from the plan. The check uses predecessors within that run, not a successful result from another run or environment. Every mandatory predecessor and all its variants must satisfy the applicable rule.
See what is missing during execution
Until sign-in has been tested successfully, the request case remains readable, but result entry is blocked. The notice identifies the unmet prerequisite. Open the predecessor, test sign-in, then refresh the prerequisites. The rule also appears beside dependency links in the detail views.
Library changes do not silently overwrite tests already in progress. When you explicitly synchronize, dependency rules are included and existing results are retained. If a relevant predecessor result changes later, the dependent test may need to be checked again. Its earlier evidence is preserved.
The test case manual explains the workflow. Download Zeta Test Management.