Studio is easy to try with one person and one test. Getting it working across an enterprise — several applications, several teams, environments that differ, people who have never met each other's tests — needs you to understand how the pieces fit.
This page is that picture: what each object is for, which level a decision belongs at, and how a test you write on a Tuesday ends up in a report someone reads at the end of the quarter.
The objects, from the inside out
| Session | A conversation with the agent. Where tests get created, changed and diagnosed. Sessions are kept, so you can reopen one rather than re-explaining yourself. Sessions are visible across your team — useful, and worth knowing before someone writes something they would not say out loud. |
| Test | One journey, one question, one pass or fail. Holds its steps, its history and its own settings overrides. |
| Project | The unit that matters most for an enterprise rollout. A project holds tests and carries the settings they inherit: access and auth, cookies, timeouts, browser behavior, execution presets. One project per application, or per application-and-environment. |
| Orchestration | A group of tests run as one job, on demand or on a schedule. This is where your smoke, critical and regression tiers live — and an orchestration can pull tests from more than one project, which is what makes a cross-application journey possible. |
| Workflow | A scheduled job written in plain language that produces a result rather than a verdict. A price watch, a daily summary. Not a test; it does not pass or fail. |
| Reports | Execution breakdown, trends per day and pass rate by project, over a date range, with export. Project-level breakdown is the reason to keep project boundaries clean. |
| Team | Who shares the work and the credits. Your connection acts as your default team; switching teams inside Studio does not move an MCP connection. |
The one structural decision: how to draw project boundaries
Almost every other decision follows from this one, because a project is where settings live and how Reports slices your pass rate.
One project per application
The default, and right for most teams. The settings that differ between applications — the login method, the cookie banner, how slow the thing is — are set once and inherited by every test in it. Reports then tell you which application is healthy, which is the question leadership actually asks.
One project per application per environment
Reach for this when staging and production differ enough that a single set of project settings cannot serve both — different hosts, different auth, self-signed certificates on one and not the other.
Before you split, try the cheaper option: one project, and an execution preset per environment. A preset is a named set of variables you choose at run time, so the same tests can run against different data or hosts without duplicating anything. Splitting projects duplicates tests; presets do not. See Test Data: Execution Presets, Variables and Secrets.
What not to do
- One project per team. It feels tidy and it breaks the settings model: two teams testing the same application now maintain two copies of the same configuration.
- One giant project. Settings become a compromise nobody is happy with, and the pass-rate breakdown stops telling you anything.
- A project per release. You lose the history that makes trends readable.
Which level to change a setting at
The rule of thumb: change it at project level so every test inherits it, and override on a single test only when that test genuinely differs.
A timeout raised on forty individual tests is forty things to maintain and forty chances to miss one. The same timeout raised once on the project is one. See Settings: Where Everything Lives and What to Change First.
How a test becomes a number someone acts on
- Somebody describes a journey in a session. A test exists.
- It is reviewed — does it assert something specific, would it go red if the thing it protects broke? See Reviewing AI-Generated Tests: What a Human Still Has to Check.
- It passes three times in a row, and joins an orchestration at the tier it has earned.
- The orchestration runs on a schedule, and a named person reads the result.
- Its duration and outcome accumulate into Reports, which is what you take to the monthly and quarterly conversations. See What to Measure: QE Metrics and KPIs with Studio.
Every step in that chain has an owner. The one most often left unassigned is step four, and it is the one that decides whether any of the rest matters.
Where each decision belongs
| Organization | Which applications are in scope, the plan and credit pool, and who administers users. |
| Team | Naming and tagging conventions, the tier definitions, who reads which orchestration. |
| Project | Access and auth, cookies, timeouts, browser behavior, execution presets — everything about reaching and running against one application. |
| Test | Only what genuinely differs from the project default. Every override is a small maintenance debt. |
Where to go next
- Inviting Your Team and Working Together in Studio — getting other people in, and what to agree before you do.
- Testing End-to-End Across Several Web Applications — journeys that cross systems.
- Scaling From One Team to Many — the conventions that stop it fragmenting.