Multi-Step Test Pipelines: Chain Tests That Share Browser State

Every test starts from a blank browser. That's fine when you're testing a public landing page. But most real testing starts the same way: log in first.

If you're running 20 tests against an authenticated area, that's 20 logins. Each one burns 20-30 seconds and a chunk of credits before the actual test even begins. And if your login flow involves 2FA or a CAPTCHA, good luck automating that reliably every single time.

We built pipelines to fix this.

The problem with isolated tests

Single-shot tests work well for simple flows. Navigate to a page, click some things, verify the result. But real user journeys aren't isolated. They're sequential.

Think about testing an e-commerce checkout:

1. Log in
2. Add items to cart
3. Go through checkout
4. Verify the order confirmation

You could write one massive test that covers all four steps. But that test becomes fragile, hard to debug, and impossible to reuse. If the login part fails, you get zero signal about whether checkout actually works.

Or you could split it into four separate tests. But then each one starts from scratch. The cart test doesn't know you just logged in. The checkout test doesn't know you just added items.

Neither approach is great.

How pipelines work

A pipeline chains multiple test plans together and runs them sequentially on the same browser instance. Cookies, localStorage, sessionStorage - everything persists from one step to the next.

Each step is its own AI agent conversation. The agent doesn't remember what happened in previous steps, but it doesn't need to. The browser state carries everything forward. If step 1 logs in, step 2 is already logged in. If step 2 adds items to a cart, step 3 sees those items.

The key pieces:

• Same browser - One browser instance stays open for the entire pipeline
• State persists - Session data, cookies, DOM state all carry forward
• Independent agents - Each step gets a fresh agent conversation with its own prompt
• Fail-fast option - Check "Fail entire test if a pre-step fails" to abort remaining steps when something breaks

This means you can build a reusable "Login" test plan and attach it as a pre-step to any test that needs authentication. Write it once, use it everywhere.

Setting it up

Two things to do: create the reusable pre-step, then attach it to your main test.

Create a reusable login step

Make a new test plan with input parameters in the prompt:

Go to https://myapp.com/login and sign in with email {{ input.email }} and password {{ input.password }}

The {{ input.xxx }} syntax declares parameters that get filled in when this test plan is used as a pre-step. You can also set defaults:

{{ input.email | 'fallback@test.com' }}
{{ input.email | credentials.email }}

The second form pulls the default from your stored credentials, which keeps secrets out of the test plan text.

Check the "Use as a pre-step for other test plans" checkbox if you want a reminder of the syntax.

Attach it as a pre-step

Create your main test plan (the one that actually tests something). Click "Add pre-step" and select the login step. The UI shows input fields for each parameter the pre-step expects.

For credential values, click the key icon next to any input field to pick from your stored credentials. This inserts {{credentials.email}} or {{credentials.password}} as the input value.

That's it. When you run the main test, it executes the login step first, then your test - all on the same browser.

Credentials stay secure

When you reference stored credentials in a pipeline, the AI agent never sees the actual values. Not in the prompt, not during the conversation, and not in the logs.

Your real passwords and secrets are only used at the moment the browser types them into a form field. Everything before and after that point uses placeholders. Test reports also redact credentials, so sensitive values never show up in results or screenshots.

What the reports look like

Each pipeline step generates its own report with screenshots, steps, and pass/fail status.

While the pipeline is running, you see a progress bar with step badges at the top. The active step shows a spinner. Completed steps show a checkmark or X. You can click any completed step to review its screenshots and prompt.

On the runs page, pipeline jobs are grouped into a single row with a "Pipeline" badge. Click through to see all steps.

Pipelines vs cookie injection

We already support cookie injection for testing authenticated flows. So when should you use which?

Use cookie injection when:

• You just need to skip the login page
• You can easily extract session cookies from your app
• You're running tests in CI where speed matters most
• Your auth flow uses external providers (Google, GitHub SSO) that are hard to automate

Use pipelines when:

• You're testing the login flow itself
• Your app uses HTTP-only cookies that are hard to extract
• You need multi-step setup beyond just auth (create data, configure settings, then test)
• You want reusable building blocks that non-technical team members can compose

They're not mutually exclusive. You can use cookie injection for most tests and pipelines for the ones that need actual browser interaction during setup.

What we're testing with pipelines

A few patterns we've been running internally:

• Login then CRUD - Log into the dashboard, create a test plan, verify it appears, delete it, verify it's gone. Four steps, each reusable.
• Onboarding flow - Sign up with a new account, complete the onboarding wizard, then verify the dashboard state. The signup step is reusable for any test that needs a fresh account.
• Multi-role testing - Log in as an admin, create an invite link. Log in as a new user (different step), accept the invite. Verify both accounts see the right state.

The "Login then CRUD" pattern is the one we find ourselves reaching for most. Having a battle-tested login step that every other test can reference saves a lot of duplication and makes the whole suite more reliable.

Adding pipeline support to your existing tests

If you already have test plans, adding pipelines is straightforward. Create a login step with input parameters, then edit your existing tests to add it as a pre-step. Your test prompts don't need to change - they just stop needing to include "first, go to the login page and sign in" at the beginning of every instruction.

Fewer instructions per test means less room for the agent to get confused. And if your login flow changes, you update it in one place instead of twenty.

Build reusable test steps and chain them into pipelines. Try Test-Lab - same browser, shared state, no repeated logins.