Shared steps are most useful when they reduce repeated work without making test cases harder to understand. Treat them as shared testing assets that need clear names, careful updates, and regular review.
Good shared step candidates include:
Avoid shared steps for one-off logic, rapidly changing flows, or steps that are tightly tied to a single test case.
Use workspace shared steps for flows that should be available across projects. Use project shared steps for flows that belong to one project.
When a flow is useful in only one project, keep it local. When multiple projects need the same flow, consider moving it to the workspace level.
A shared step should represent a focused reusable action or short flow.
Better:
Too broad:
Smaller shared steps are easier to reuse, review, and safely update.
Use names that describe the user action or test activity. Add descriptions that explain when the shared step should be used and what assumptions it makes.
Clear names and descriptions help teams choose the right shared step from the picker.
Parameters work well inside shared steps when a repeated value may change, such as a URL, test account, or environment name.
For example, a shared step can say:
Open $application_login_url.This keeps the shared step reusable while allowing the value to be managed from the Parameters page.
Editing a shared step can affect every test case that uses it. Before changing a shared step:
Workspace shared steps deserve extra care because they can be used across projects.
When deleting a used shared step, Convert to regular step keeps the step content inside linked test cases and removes the shared link.
Use Remove from usages only when the step should disappear from linked test cases.
Over time, shared step libraries can become noisy. Periodically review:
Small cleanup habits keep the picker useful and reduce mistakes.