> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qa.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Shared Steps

> Reuse the same sequence of steps across multiple tests using dependencies, agent knowledge, or assistant docs

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](/core-concepts/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.

<Tip>
  Keep tests to 10 steps or less. If a workflow is longer, split it and chain
  with a dependency instead of one giant test.
</Tip>

**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**](/core-concepts/knowledge#test-agent-tab). 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:

```md theme={null}
## 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](/core-concepts/knowledge#library) (or an Assistant Rule). The [AI Chat Assistant](/core-concepts/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).