Variants

What a variant is

An application in OttoTester is a product you test. A variant is one deployment of that product. One application can have many variants.

You’ll usually have:

One variant per environment — dev, staging, prod. Same app, different URLs.
Sometimes one variant per section of a large app — for example, a separate variant for an admin portal that lives at its own URL.

Each variant has its own base URL, and OttoTester treats it as a self-contained testing target.

What a variant holds

A variant owns everything tied to its deployment:

Base URL — where the planner starts exploring.
Browser settings — viewport, locale, and timezone. (Pacing for apps that rate-limit fast automation — slow-motion between actions and a pause between tests — is set on the run templates, not the variant.)
Auth fixtures — how OttoTester signs in. See Fixtures and test data.
Discovered pages — the pages the planner found while exploring, with snapshots the generator and healer reuse.
Test cases — everything the planner has generated for this variant.

A test run always targets exactly one variant.

Configuring trigger rules and notifications per variant

Two settings vary per variant — the trigger rules that fire runs against this variant, and any Slack channel override that steers where this variant’s notifications go. Both live on the application → Integrations tab rather than on the variant itself: each integration card (GitHub, Slack) lists every variant under it, and clicking a variant opens a drawer for that variant’s settings.

Trigger rules — rules that fire a run against this variant when your deploy platform reports a successful deployment to GitHub. From the application’s Integrations tab, click this variant under the GitHub card. The drawer lists every rule pointing at this variant’s Replay templates. Click Add trigger rule, pick a template, optionally set an Environment filter (Preview, Production, or any label your deploy platform uses), save. OttoTester runs the template against the deploy’s actual URL — not the variant’s static default — so a PR’s preview deploy gets tested against the preview. Rules live per-variant because each variant has its own templates; the rules you write here only fire against this variant. See Connect to CI/CD for the three customer flavors (PaaS like Vercel or Netlify, GitHub Actions with Environments, bare GitHub Actions deploy steps).
Notifications — per-variant overrides on top of the application’s default Slack channel. Click this variant under the Slack card to open its overrides drawer. By default, this variant inherits the application’s Slack channel for run notifications. If this variant needs a different channel — for example, prod notifications going to #prod-alerts while staging stays in #staging — add the override here. With no override, the variant inherits the app default; if neither is set, the notification is silent.

Both settings require the workspace’s GitHub or Slack connection to be in place first. See Connect to CI/CD for the three-step setup.

When to create a new variant

Create a new variant when the URL or environment changes. Staging and prod are two variants because they’re two URLs — even though it’s “the same” app.

Don’t create a variant for things that aren’t a separate deployment:

Not one per test case — test cases live inside a variant.
Not one per browser — the browser is a setting on the variant and on replay templates, not a reason to split.

Add a variant

On the application’s page, click Add variant. Give it a name (usually the environment — prod, staging, dev), set the base URL OttoTester should start exploring from, and adjust browser settings if you need a specific viewport, locale, or timezone.

You can stop there. The first test run from this variant triggers a scan that fills in the rest — discovered pages, an inferred application summary, and a starter set of test cases — automatically.

If the variant needs sign-in, set up a fixture before the first run. See Set up authentication.

Concept → Test Authoring Templates, Tests, Fixtures and test data
Workflow → Quickstart