> For the complete documentation index, see [llms.txt](https://docs.bugbug.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bugbug.io/editing-tests/grouping-steps.md).

# Grouping steps

How BugBug organizes test steps into groups: the default group, splitting, renaming, moving and removing groups, copying steps between groups and tests, and how groups relate to components.

Every step in a BugBug test belongs to a group. Groups split a long test into named parts, such as "Log in", "Add product to cart" and "Check out", so the test is easier to read and edit. A group can also be turned into a [component](/editing-tests/components.md) and reused in other tests.

{% hint style="info" %}
**In short**

* A step is always inside a group. A test is an ordered list of groups, and each group is an ordered list of steps.
* When you record a new test, the steps go into one group. Split it into smaller groups afterwards.
* Groups run in order, one after another. A group doesn't change how its steps run.
* Groups can't be nested: a group contains steps, not other groups.
* A group belongs to one test. To share steps between tests, make the group a [component](/editing-tests/components.md).
  {% endhint %}

## Split a group

The quickest way to create groups is to split one:

1. Hover between two steps in the group.
2. Click the **+** icon.
3. Click **Split here**.
4. Name the new group.

The steps below the split point move to the new group, placed right after the original one. The original group keeps its name.

![](https://3168433179-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MKixgeBPbLvnD0l1eiV%2Fuploads%2FUNrwsakVHrH2jbpQlAZC%2Fsplit-group-here.png?alt=media\&token=bfe1fa8f-6b4e-48fd-b3bc-d034de8b7c83)

If you don't give a group a name, BugBug names it `Group number <n>`.

## Rename a group

Click the group's name and type the new one. It's saved automatically. Group names don't have to be unique; [component](/editing-tests/components.md) names do.

## Reorder groups and steps

* Drag a group to move it, with all its steps, to another place in the test.
* Drag a step to move it within its group or into another group.

## Copy and paste steps

You can copy steps and paste them in the same test or in another test:

1. Copy one step with **Copy step**, or select several steps and use **Copy**. The selection can include steps from several groups and components.
2. Paste them:
   * between two steps: hover between them, click the **+** icon and choose **Paste step(s)**, or
   * at the end of the test: use the paste action below the test, which shows the number of copied steps (for example **Paste 3 steps**).

Only the steps are pasted, not the groups or components they came from. Steps copied from a component become ordinary steps in the target group and aren't linked to the component.

## Remove a group

Removing a group from a test removes its steps from the test. A regular group belongs to one test, so its steps are deleted. A [component](/editing-tests/components.md#remove-a-component-from-a-test) is only removed from that test and stays in the project.

## Variables between groups

Groups don't limit variables. A variable set with **Set variable** in one group can be used in every later step of the test, in any group or component. This is how you [run a component with different values](/editing-tests/components.md#run-a-component-with-different-values).

## Groups and components

|                           | Regular group          | Component                                        |
| ------------------------- | ---------------------- | ------------------------------------------------ |
| Used in                   | One test               | Any number of tests, and more than once per test |
| Editing its steps         | Changes this test only | Changes every test that uses it                  |
| Name                      | Any                    | Unique in the project                            |
| Removing from a test      | Deletes its steps      | Keeps the component in the project               |
| Listed on Components page | No                     | Yes                                              |

To turn a group into a component, click **Make component** on its header. See [Components](/editing-tests/components.md).

## FAQ

<details>

<summary>Does every step have to be in a group?</summary>

Yes. A test is built from groups, and steps live inside them. A newly recorded test has all its steps in one group, which you can split later.

</details>

<details>

<summary>Can I put a group inside another group?</summary>

No. Groups can't be nested. To structure a long flow, split it into more groups at the same level, or use an [if block](/editing-tests/conditional-logic-if-else.md) inside a group to run some steps conditionally.

</details>

<details>

<summary>Does a group affect how its steps run?</summary>

No. Groups only organize steps. The test runs all steps of the first group, then all steps of the next one, and so on.

</details>

<details>

<summary>Can I use a group in another test?</summary>

Not as a regular group. Make it a [component](/editing-tests/components.md) and insert it into the other test, or [copy its steps](#copy-and-paste-steps) and paste them there. You can also start a new test from a point in an existing one with [New test from here](/creating-tests/new-test-from-here.md).

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.bugbug.io/editing-tests/grouping-steps.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.