Studio's settings sit at two levels — project and test — with the same structure in both. This article maps every section so you know where to look, and explains the one idea that makes the whole thing make sense: defaults at the project, exceptions at the test.
Tip: click any screenshot to open it full size.
The two levels
| Project Settings | Defaults inherited by every test in the project. Open the project and choose Settings. |
| Test Settings | Overrides for a single test. Open the test and click the gear in the top toolbar, between Quick Select and Run Test. |
Most settings at test level carry an Override project default toggle. Off means "follow the project". On means "this test is different".
The practical rule: change the project, not the test. A setting tuned on forty individual tests is invisible and impossible to reason about. A project default with three deliberate exceptions is something a colleague can understand.
What is in each section
General → Test details / Project details
Identity and organization: name, project, tags, description, folder.
Tags are worth more attention than they usually get — they drive filtering, orchestration
membership and reporting. A consistent tag scheme (smoke, checkout,
slow) is what lets you build an orchestration by meaning rather than by hand-picking
tests. See
Understanding a Test Run and Its Results.
The description field is where you record why a test exists or why it overrides a default. Use it.
Execution → Timeouts
How long the runtime waits before giving up. Reach for this when an application is genuinely slow rather than broken.
Execution → Execution behavior
The most consequential section, covering how tests recover from trouble: Continue on error, Continue on verification failure, Fail if element invisible, Max verification failures, Timing model and Self heal.
The last two are the self-healing controls, and they get their own article — Self-Healing and Timing: Controlling How Studio Recovers.
Execution → Execution presets (project only)
Reusable variable sets. Select a preset when running tests or starting a session and its variables are applied automatically - the way to point the same tests at different data or environments without duplicating them.
Access & Auth
Five sections for reaching applications that are not simply open on the public internet:
| Cookies | Pre-set cookies before the test starts — feature flags, consent, locale. |
| Custom HTTP headers | Headers sent with every request. |
| Basic authentication | For environments behind HTTP basic auth. |
| Certificate handling | How to treat certificates, including ones a browser would normally refuse. |
| Mutual TLS | Client-certificate authentication. |
These usually belong at project level — an environment's access requirements apply to everything pointed at it.
Advanced → Browser behavior
Locale, Open Shadow DOM, video recording and screenshot capture. Not a section to skip: if your application uses web components, Shadow DOM is the setting that makes its controls reachable at all.
A worked order of operations
When a new application misbehaves, work down this list rather than changing things at random:
- Can the runtime reach it at all? If not, that is Access & Auth — basic auth, a certificate, a required header.
- Does it load but too slowly? Timeouts, then Timing model toward Conservative.
- Does it work but break on every redesign? Self heal toward Aggressive — but read the caveats first.
- Do you need to see all failures in one run rather than stopping at the first? Continue on verification failure.
- Only now consider a per-test override, and write down why in the description.
You can change most of this by asking
The agent understands these settings in plain language, and doing it that way leaves the reasoning in the test's conversation where the next person will find it:
This environment is slow - extend the page-load timeout for this test.Be more conservative about self-healing here; this test checks pricing.Tag this test as smoke and checkout.A caution about overrides
Every override is a small piece of hidden state. Six months later, a test that behaves differently from its neighbors with no explanation is a genuine time sink to debug.
If you override something, say why in the description field. If you find yourself overriding the same setting on many tests, that is not a set of exceptions — that is your project default being wrong. Change it there instead.