Scenarios

Describe the outcome, not the clicks

A scenario is versioned YAML — an objective, a role, assertions and budgets. No selectors, no coordinates, nothing to rewrite when the interface changes.

Overview

Objectives, not scripts

A scripted test encodes how the interface looked on the day it was written, which is why a redesign breaks tests whose business process still works perfectly. An Argus scenario states the objective, the role and what must be true at the end, and lets the agent work out the clicks — so the test survives changes that would have broken a script.

What it does

Tests that outlive the layout

A scenario is an objective, a role, assertions and budgets.

No selectors and no coordinates to maintain.

A redesign does not invalidate the test.

Scenarios are versioned YAML, reviewable like code.

App-specific quirks live in one shared notes file, not per scenario.

How it works

How a scenario is written

1State the objective in plain language
2Name the role it runs as
3Declare the assertions that must hold
4Set step and time budgets
FAQ

Common questions

What replaces the selectors?

Nothing needs to. The agent perceives the live screen and works out the interaction itself.

Where do credentials go?

Never in the scenario. A role name resolves through an encrypted secret store, and login is scripted deterministically.

How do we stop a scenario running forever?

Each one carries step and time budgets, alongside loop and stall detection.

Explore more

More of what Argus QA does

Get started

See agents test your own application

Request a demo to watch a multi-role regression suite run through your real interface.