Most teams run the same critical flows against more than one deployment: a dev build while a feature is in progress, a staging environment before release, and production for smoke checks. You do not want three copies of the same tests drifting apart. In TestVibe, one project holds one suite of generated features, and you choose which environment each run targets — this guide covers the URL strategy, how variables travel across environments, and what belongs where.
One project, many environments
A TestVibe project is created with a name and a base site URL — the address your tests open. You add the rest under Settings → Environments, where a project can hold multiple test site URLs (for example staging, QA, and a preview build) with one marked as the default. The default is used whenever a run does not specify anything else.
Good environment URLs share one trait: they are stable and reachable by a cloud test session. A shared staging URL, a QA environment, or a public preview build all work well. Two things to avoid:
localhost— a cloud session cannot reach your machine. If you need to test a local or private, VPN-only environment, connect a tunnel device; the URL stays unchanged and nothing inbound is opened.- One-off URLs saved as permanent environments. For a throwaway target, use the Custom URL option at run time instead of cluttering the environment list.
Keeping every environment in one project is the point. The features, generated Playwright specs, run configurations, and history live in one place, and you can validate the same selected behavior across targets instead of maintaining parallel suites.
Picking the target at run time
When you start a run from Runs → New Run, the composer has an Environment field. Pick a configured environment, or drop in a Custom URL for a one-off target, then choose one or more run configurations and start. The same picker appears whether you run a single test, a group, or the full suite — the selection is what points that run at dev, staging, or prod.
Automations follow the same model. When you build a scheduled or event-triggered automation, the Run features action takes an explicit site URL, or falls back to the project's site URL:
| Site URL source | When to use it |
|---|---|
| Explicit URL | The automation should always hit one specific environment. |
| Project site URL | The project already defines the correct target. |
For anything recurring, prefer an explicit URL. A nightly regression should name the staging environment it is meant to validate rather than inheriting whatever the project default happens to be that week.
Variables and secrets across environments
Sign-in credentials, API tokens, and configuration values are stored per project under Settings → Variables & Secrets. Secrets are write-only — once saved, the value is never shown again — and both are injected into generation and test runs at run time. You reference them from Gherkin with runtime tokens, instead of literal values in the feature file. Known secrets are redacted from transcripts; review screenshots and traces for sensitive page content:
When I sign in with username "{{var:LOGIN_USERNAME}}" and password "{{secret:LOGIN_PASSWORD}}"Review the project’s variables and secret references for the intended target. A project-scoped secret name does not automatically select separate staging and production credentials.
Because these values are a single per-project namespace, plan them with multi-environment use in mind. Two patterns work well:
- One shared test identity. If the same test account exists in dev, staging, and prod (when deliberately configured for that identity), a single
LOGIN_USERNAME/LOGIN_PASSWORDpair covers every environment. The feature does not care which URL it runs against. - Environment-prefixed names. When credentials genuinely differ, give them explicit names —
STAGING_API_TOKEN,QA_API_TOKEN— and reference the right one in the steps or setup that need it. Selecting an environment URL does not automatically choose aSTAGING_orQA_credential; verify the saved spec uses the intended value. It is more verbose, but it keeps each value unambiguous.
Either way, use dedicated test accounts rather than personal ones, and never paste a raw key into a step — always go through a {{secret:...}} token.
What to run where
The same suite behaves differently depending on the environment, mostly because of blast radius and data. A rough division:
| Environment | Typical scope | Why |
|---|---|---|
| Dev | Single tests and small groups | Fast feedback while a flow is still changing; run the one test you are iterating on. |
| Staging | Full suite and nightly regression | Broad confidence before shipping; confirms the deployment is usable end to end. |
| Prod | Read-only smoke checks on critical paths | Checks selected live paths; sign-in can still create sessions and load. |
Two cautions that come from testing practice, not the tool. First, be deliberate about data-mutating flows in production — a test that places an order or edits a record against the live site leaves real state behind. Reserve production runs for read-only critical paths (can users load the homepage, sign in, reach checkout) and keep the destructive flows on staging. Second, point recurring automations at a stable environment. A staging build that resets overnight will fail for reasons unrelated to your app, and you will spend mornings triaging noise instead of regressions.
A full suite is best after individual tests and key groups are already green, so a natural progression is: iterate a test on dev, promote it into the staging nightly, and add its critical path to a lightweight production smoke run.
Wrapping up
One project, one suite, a short list of environment URLs, and a run-time picker is all it takes to cover dev, staging, and prod without duplicating tests. Keep variables planned for reuse, match run scope to each environment's risk, and let automations carry the recurring passes. Ready to point your own suite at every environment? Get early access, or read more in the environments docs.