The pilot worked. One team, one application, a suite people trust. Now three more teams want it, and the question is no longer whether Studio works — it is whether what you built can be repeated without fragmenting into four incompatible ways of doing the same thing.
This page is the small set of conventions that make that possible, and the two numbers that tell you whether it is working.
Write down five things. That is the whole governance model.
Resist the urge to write a standards document. Five decisions, on one page, that every team adopts:
| 1. Project boundaries | One project per application, or per application and environment. Never per team, never per release. |
| 2. Test naming | Something that reads as a sentence about behavior. “Guest can order and see the correct subtotal” beats “TC-1042 checkout regression”, because the first tells a stranger what a red result means. |
| 3. Tier tags | Three tags: smoke, critical, regression. The test list filters by tag, and that is how orchestrations stay in step with intent as tests are added. |
| 4. Promotion rule | Nothing enters a tier that gates a release until it has passed three times in a row. Written down, this survives the person who invented it. |
| 5. Who reads red | Per orchestration: a named person, a timescale, and what “done” means. Never “it passed on the rerun”. |
Everything else — how someone phrases a prompt, how many tests they write, which order they work in — leave alone. Teams that are trusted to work their own way adopt faster, and the five rules above are the only ones that stop the suite becoming unreadable across team boundaries.
Sequence the teams, do not launch them
The instinct is a company-wide kickoff. It produces a lot of accounts and very few tests.
- The pilot team keeps going. They are your evidence and your support desk.
- Team two starts about a month later, with the pilot's environment checklist and conventions in hand. Their job is partly to find out which parts of the pilot's approach were specific to the pilot.
- Teams three and four go together, once the conventions have survived contact with a second application.
- After that it is self-serve — the exercise series, the lab handouts, and a named person to ask.
Each new team still does the work in Before You Point Studio at Your Own Application for their own system. Access is per application, and it is where week one disappears if nobody checks.
What travels between teams, and what does not
| Travels | The five conventions · the exercise series and its lab handouts · the habit of diagnosing before fixing · the review checklist · a skill, if teams share an application · whatever your pilot learned about your estate's authentication |
| Does not travel | Project settings, which are per application · execution presets, which are per environment · tests, which are per application · the tolerance for flake, which has to be re-established with each team |
Give each application a skill
At one team this is a nice-to-have. At four it is the thing that keeps quality even, because it stops every tester teaching the agent their own private version of the application.
A skill is a short document — two or three pages — describing what the application is, what its words mean, its critical journeys and its quirks. It is installed in each person's AI tool, beside the Functionize MCP connection. Distribute it centrally, through your organization's tool provisioning or a repository everyone pulls from; if people copy it around by hand, an update reaches nobody. See Why Skills Matter, and note that we build these for customers.
Credits across several teams
Credits pool, so a team building heavily draws on the same balance as a team that is mostly running. That is usually what you want, and it means two things are worth saying out loud early:
- Month one of each new team looks expensive, because building is the heavy part. That is the front-loaded curve, not a problem. Explain it before the invoice rather than after.
- The efficiency number to watch is credits per test maintained per month. It should fall as each team's suite matures. Rising means people are regenerating tests instead of fixing them — a training issue, not a pricing one.
See How Credits Work.
Reporting upward without drowning
Reports breaks pass rate down by project, which is the payoff for keeping project boundaries clean: each application's health is legible on its own.
Three numbers go up the chain, monthly, and only three:
- Escaped defects — the north star. Everything else is a proxy.
- Critical journey coverage — per application, against a list each team wrote themselves.
- Manual regression hours displaced — the easiest number for a finance conversation, and usually the largest.
Pass rate is an internal diagnostic. Test counts are not a metric at all. See What to Measure: QE Metrics and KPIs with Studio.
The two numbers that tell you scaling is working
Checked quarterly, per team:
- Maintenance share is falling. The proportion of automation effort spent repairing rather than adding. This is the number Studio targets directly, and a team whose maintenance share is not falling has a convention problem or a skill problem, not a tool problem.
- Time to a team's first reliable test is shrinking. Team one took two weeks. If team four takes two weeks as well, nothing is being carried forward — which means the conventions are written down but not actually being handed over.
The four ways this goes wrong
| A standards document nobody reads | Five rules on one page get followed. Forty pages get ignored, and then the rules are blamed rather than the length. |
| A central team that writes everyone's tests | It becomes the bottleneck it was meant to remove, and the people who know the application stop being involved. Central teams should own conventions and onboarding, not authorship. |
| Launching every team at once | Nobody has been through it yet, so every team hits the same access problem independently and concludes the tool does not work. |
| Counting tests | The moment test count becomes a target, you get cheap tests. Report what is proven, never what was written. |
Where to go next
- How It All Ties Together: Studio Across an Enterprise — the object model behind these conventions.
- What to Measure: QE Metrics and KPIs with Studio — with a printable tear sheet.
- Keeping a Suite Green: Flake, Tiers and Who Owns Red — the tier model the tags refer to.