When several tests start with the same sequence (log in, navigate to a page, set up data), you don’t have to rewrite those steps in every test. QA.tech gives you three ways to share steps, each with different trade-offs. Pick based on whether the steps should run once and be reused, run fresh every time, or be copied into each test.
Quick comparison
| Approach | Steps run… | Best for | Not good for |
|---|
| Dependencies | Once, then reused | Login, navigation, expensive setup you don’t want to repeat | Creating multiple new things (steps only run once) |
| Agent knowledge (Agent Rule) | Fresh on every test | Repeated procedures the chat struggles to generate, including creating new things | One-off steps; long procedures consulted on every action |
| Assistant docs (Library knowledge) | Copied into each test at creation | Self-contained tests you want to edit per-test | Keeping many tests in sync (copies are static) |
Option 1: Dependencies
Put the shared steps in their own test, then have other tests depend on it. With Resume From, dependent tests inherit the browser state (login session, cookies) so the steps don’t run again. See Test Dependencies for Resume From vs. Wait For.
Use when: the steps establish state you want to reuse and don’t want to repeat - logging in, navigating to a starting page, or expensive one-time setup.
Avoid when: each dependent test needs the steps to actually run again - for example creating a new record per test. Resume From runs the parent once and reuses its end state, so it can’t create a fresh thing for every child.
Keep tests to 10 steps or less. If a workflow is longer, split it and chain
with a dependency instead of one giant test.
Pros: real shared session and state, no repeated work, fast for large suites that share a login.
Cons: dependent chains run sequentially; each test has a single Resume From parent; steps execute only once.
Option 2: Shared steps as agent knowledge
When the chat has trouble generating a tricky sequence reliably, or you need the steps to run fresh every time (like creating a new entity), write them once as an Agent Rule under Settings → Knowledge → Test Agent. The test agent reads matching rules during execution, so you can reference the procedure by name in a test step instead of spelling it out each time.
Write the steps in clear LLM-friendly syntax
Give the rule a short, unique title and a numbered procedure:
## Shared steps: Create a project
Use these steps whenever a test needs a new project.
1. Click "New project" in the top navigation.
2. Enter a unique project name.
3. Select the "Blank" template.
4. Click "Create" and wait for the project dashboard to load.
Reference it from a test step
In the test, point at the rule by its title rather than repeating the steps:
Follow the “Create a project” shared steps, then open Settings and rename the project.
Filter so it only loads where needed
Agent Rules support targeting filters - application, labels, scenario, or URL path. Set a scenario or URL path filter so the procedure is only loaded for tests that need it and doesn’t add noise to unrelated tests.
| Filter | Example | Effect |
|---|
| Scenario | Projects | Loaded only for tests in the Projects scenario |
| URL path | /projects | Loaded only when the test starts under /projects |
Pros: runs fresh every time (works for creating new things), one source of truth referenced by name, targeting keeps it out of unrelated tests.
Cons: Agent Rules are consulted on every relevant action, so keep procedures concise; it is guidance the agent follows, not a guaranteed macro.
Option 3: Shared steps as assistant docs
If you’d rather the steps live inside each test as normal, editable steps, add them as a text item in your Knowledge Library (or an Assistant Rule). The AI Chat Assistant searches your knowledge when creating or editing tests and copies the steps into the test definition.
Use the “Create a project” steps from my knowledge to start this test, then verify the dashboard loads.
Pros: each test is self-contained and individually editable; no runtime dependency or rule needed.
Cons: the copied steps are a static snapshot - updating the knowledge item does not update tests already created from it. Re-ask the assistant to re-apply if the procedure changes.
Which should I use?
- Login, navigation, or setup you don’t want to repeat → Dependencies (Resume From).
- A procedure the agent must run every time (e.g. create a new record) or struggles to generate → Agent knowledge, filtered by scenario or route.
- You want the steps written into each test so they’re self-contained and editable → Assistant docs (accepting they’re static copies).