# New feature: Test import, export & backup with YAML
Written by Dominik Szahidewicz
Reviewed by Mariusz Wójcik
Published: 2026-08-24
Updated: 2026-08-25
\[TABLE\_OF\_CONTENTS\]
Your tests can now move in and out of BugBug as human-readable YAML.
Export a single test for review, editing, or version control. Export a complete project as ZIP for backup. Import tests back into BugBug when you need them.
The goal is simple: make visually created tests easier to keep, review, share, and work with outside the recorder.
`{"name":"yellow-tip","children":[{"name":"yellow-tip-title","children":[{"name":"paragraph","children":[{"attributes":{"bold":true},"data":"💡 Import and export are available on every BugBug plan, "},{"attributes":{"linkHref":"https://bugbug.io/pricing/","bold":true},"data":"including FREE"},{"attributes":{"bold":true},"data":"."}]},{"name":"paragraph"}]},{"name":"yellow-tip-details","children":[{"name":"paragraph"},{"name":"paragraph"}]}]} **💡 Import and export are available on every BugBug plan,** [**including FREE**](https://bugbug.io/pricing/)**.** `
## Why do you need it?
Visual test automation makes tests easier to create, but teams often need to work with those test assets outside the visual editor too.
Product teams may want to keep creating customer journeys visually. QA needs to maintain regression coverage. Developers may want to inspect changes, keep files in Git, or work with structured definitions in their existing workflows.
BugBug YAML gives all of them access to the same test definitions.
### Keep your test definitions outside BugBug
Exported tests remain readable outside the platform. You can keep them with the rest of your code, review changes in a diff, edit them, and maintain your own copies.
### Make test changes easier to review
Because tests are stored as structured text, changes can be inspected before they are imported back into BugBug.
That makes it easier to answer a simple question:
> What exactly changed in this test?
### Back up more than an individual test
A full project export can contain:
* tests
* reusable components
* suites
* profiles
* project settings
* folder structure
* upload attachments
* visual regression baselines
So you can keep a complete copy of the test assets and files your project depends on.
## How does it work?
BugBug supports two export formats: YAML and ZIP.
### Export a single test as YAML
A YAML file contains the test definition: its steps, settings, and references to reusable components.
For example:
```css
schema_version: '1.0'
schema_type: test
data:
test_name: Sign in
groups:
- group_name: Login
steps:
- action: goto
action_details:
url: https://example.com/login
```
The format is structured and readable, so it can be inspected or edited outside BugBug.
If the test uses a [reusable component](https://docs.bugbug.io/components), YAML references that component rather than copying it into the file. This keeps the test definition smaller and easier to review.
### Export as ZIP when you need dependencies
A ZIP bundles the exported item with the dependencies and files it needs.
Use ZIP when a test or project needs to travel together with assets such as:
* reusable components
* upload attachments
* [visual regression baselines](https://docs.bugbug.io/visual-regression)
A complete project ZIP also includes suites, profiles, settings, and folder structure.
### Import tests back into BugBug
You can import an individual test as YAML or ZIP into an existing project.
BugBug identifies tests and components by their slug.
If an incoming test already exists, BugBug shows the current and incoming YAML side by side so you can decide whether to:
* overwrite the existing version
* skip it
* cancel the import
A whole project ZIP works differently: importing it always creates a new project instead of overwriting an existing one.
### Validate YAML in your editor or CI
Every exported BugBug YAML file references the BugBug JSON Schema.
Compatible editors can use it for autocomplete and validation. The same schema can also be used in [your CI pipeline](https://docs.bugbug.io/cli) to catch invalid YAML before import.
## What are the benefits?
### Product teams can keep working visually
Product teams can record and maintain critical workflows in BugBug without needing to work directly with YAML.
The [visual recorder](https://bugbug.io/blog/test-automation-tools/web-test-recorder/) remains the interface for creating and understanding the test.
### QA gets readable, portable test definitions
QA can export tests, keep copies outside the platform, review changes, and bring them back into BugBug.
For larger backups, project ZIPs keep related tests, components, suites, profiles, settings, and artifacts together.
### Developers can work with structured test assets
Developers can inspect YAML, review diffs, store files in Git, and work with the same test definitions through engineering workflows.
The result is less duplication between visually created regression tests and the structured assets engineering wants to review.
### One test can serve different roles
Product teams can work visually. QA can manage the regression suite. Developers can inspect and version structured files.
They are still working with the same BugBug test assets, rather than maintaining separate versions of the same customer journey.
## One important distinction: YAML is not executable test code
BugBug YAML describes **what** a test does — the steps, the settings, the components it reuses. It is not standalone Playwright, Cypress, or Selenium code, and a `.bugbug.yaml` file will not run on its own. Import it into BugBug and execute it:
* locally
* in BugBug Cloud
* [from your CI pipeline](https://docs.bugbug.io/cli)
That is the trade-off, stated plainly: BugBug remains the environment that runs your tests.
But readable, structured text has a second life. Hand a `.bugbug.yaml` file to Claude, ChatGPT, Cursor, or whatever your team already uses, and ask for the same flow as a Playwright spec — the steps, selectors, and assertions are all there in plain text for the model to work from. Same for Cypress, Selenium, or an internal framework nobody outside your company has heard of.
That gets you a working draft, not a finished suite. You will still review selectors, waits, and assertions the way you would review any generated code. But the starting point is your actual recorded flow, not a blank file and a description from memory.
Which means the real question — _what happens to my tests if I leave?_ — has a better answer than "you export a file you can read." You export a file your team, and your AI tooling, can act on.
## Available now on every plan
YAML and ZIP import/export are available on [all BugBug plans, including FREE](https://bugbug.io/pricing/).
Build tests visually. Keep the definitions as YAML. Back up the complete project when you need to.
`{"name":"purple-tip","children":[{"name":"purple-tip-title","children":[{"name":"paragraph","children":[{"attributes":{"bold":true},"data":"💡 "},{"attributes":{"bold":true,"linkHref":"https://bugbug.io/yaml/"},"data":"Explore YAML import & export in BugBug "}]},{"name":"paragraph"}]},{"name":"purple-tip-details","children":[{"name":"paragraph"},{"name":"paragraph"}]}]} **💡** [**Explore YAML import & export in BugBug**](https://bugbug.io/yaml/) `