Actor scenarios

A chain runs test A, then test B. A scenario says the Customer submits, the Manager approves, and the Customer sees the decision — and the difference is not cosmetic, because the middle step only means anything if the Manager is a genuinely different session.

If you already use chains, a scenario is a chain that knows who is acting. You can import an existing chain as a scenario; the chain itself keeps working, untouched.

Actors are people, not credentials

An actor is a business persona — "Customer", "Approving Manager", "Finance". It is not an auth role. The same persona is often a different role in different projects: a Manager is an admin in your ops portal and an ordinary user in your customer portal.

So the role mapping lives on the actor, one per project. Rename the persona and every stage follows; you never retype a role id per stage.

Each stage re-establishes its actor's captured session in a fresh browser context. That is what makes "the Manager approves" a different session rather than the same browser with a new label.

What does not survive a handoff: anything held only in the page — an unsubmitted form, in-memory state, an open websocket. The session is re-established from captured cookies and storage, not resumed.

Stages run one after another

This is the V1 bound and it is worth stating plainly, because a green multi-actor run is exactly where the wrong conclusion forms.

Two actors never hold the page at the same instant. A scenario therefore cannot test live chat, presence, simultaneous-edit conflicts, or notification races. If that is what you need to verify, a scenario will pass without having tested it.

Passing values between stages

A stage can publish values — an order id, a reference — captured with an extract step and used by later stages as {{name}}. That threading is the whole point: a template that made you retype the id would just be two independent tests that happen to run in order.

Values marked sensitive stay real in memory for the next stage and are masked everywhere they are stored or displayed.

Waits

A stage can wait for a condition before it runs: an API reaching a state, an element appearing, or a plain poll. Every wait carries a timeout — there is no default meaning "forever", because a scenario that hangs is worse than one that fails: a failure names a condition and a hang names nothing.

A timed-out wait reports the actor, the stage, the condition, how long it waited, and what it last saw. That last field is the one that makes a timeout debuggable: "timed out after 60s" says a wait failed, while "timed out after 60s, last saw status=pending" tells you whether your app is slow or your condition was wrong.

What gets skipped when something fails

A chain is a line, so any failure skips everything after it. A scenario is a graph, so a stage is skipped only when something it actually depends on did not pass. A "Finance reconciles" stage that depends on nothing has no reason to be cancelled because "Manager approves" failed.

Skipped stages appear in the report with the reason. Dropping them would make a scenario that stopped after stage two look like a two-stage scenario that passed.

Cleanup

Cleanup runs after pass, failure and cancellation, and its result is reported beside the verdict rather than folded into it. A scenario that genuinely failed is not rescued by a tidy teardown, and a passing scenario whose cleanup failed still says so — loudly enough that the next run's fixtures are not a mystery.

Start from a template

Two starter templates ship with the extract step already wired:

• Operator creates it, customer sees it — the provisioning direction.
• Customer submits, operator approves, customer sees the decision — the approval loop. Its third stage is the one it exists for: without the customer coming back, the scenario proves an operator clicked approve, not that anything reached the person waiting.

Both need two projects and a role for each actor. A template will not save until each actor has a role, because a stage whose actor has no binding runs as whatever session that project happens to have captured — which is exactly the ambiguity actors exist to remove.

Validation happens when you save

Cycles, unknown actors, stages that run nothing, stages that run two things, and variables nothing publishes are all rejected at save time, with every problem reported at once against the stage it belongs to.

A scenario is minutes of browser work across several projects. Discovering on stage four that stage two never published {{requestId}} costs the whole run and tells you nothing you could not have known when you wrote it.

The report

One run, two views. Chronologically — what happened, in order — for debugging. Per actor — what the Manager did — for review, which is where you see whether the handoff was real. Both are built from the same results, so they cannot disagree.