A day-by-day plan for getting a team genuinely productive, not just logged in. It assumes one person leads the rollout and two or three others follow a week behind.
Before day one: capture the baseline
Half an hour, and it is the easiest thing to skip and the hardest to recover. Write down escaped defects last quarter, manual regression hours per release, how much automation time goes on repairs, and which critical journeys are covered today. See What to Measure: QE Metrics and KPIs.
Without this you will improve things and be unable to prove it.
Day 1 — one person, one hour
- Work through Your First 30 Minutes on the demo store. Do not skip breaking a test on purpose.
- Then Before You Point Studio at Your Own Application — work the checklist and note what your environment needs.
End of day 1: one passing test, one failure you diagnosed, and a list of access requirements.
Day 2 — make the environment work
- Configure project settings: access and auth, cookies for banners, timeouts if slow, Shadow DOM if you use web components.
- Create an execution preset for your test data and put any credentials in encrypted variables.
- Get one test passing against your own application.
If this takes longer than a day, stop and ask us. Access problems are our problem, not yours, and teams routinely lose two weeks here that a twenty-minute call would have saved.
Days 3–5 — the first real tests
- Build the three to five read-only tests from Choosing What to Automate First.
- Run them repeatedly. You are looking for flake, not for coverage.
- Fix the causes of any flake now — data, timing, banners. Flake tolerated in week one becomes flake tolerated forever.
End of week 1: a handful of tests that pass reliably, three times in a row. Reliability first, volume later.
Day 6 — bring in the others
Now, not on day one. You have a working environment and can spend the session teaching instead of debugging access.
- Give each person the exercise series and the printable lab handouts attached to each one.
- Have everyone do Exercise 5 — breaking a test and diagnosing it. If your team can only do one exercise, make it that one.
- Agree the house rules: what never goes in a prompt, how tests are named, which tags you use.
Days 7–10 — the flows that matter
- Cover the money flow, the permission boundaries, the negative cases.
- Work through last quarter's escaped defects and write a test for each.
- Ask us for a skill for your main application, or write a first draft yourself. Everything gets sharper once the agent knows your domain.
Days 11–14 — make it a habit
- Group the fast, reliable tests into a smoke orchestration. Keep it small.
- Schedule it — daily to begin with.
- Name the person who reads the result and what they do when it is red. This single decision separates suites that survive from suites that rot.
- Connect one person's editor over MCP so tests can be created where the work happens.
- Put a recurring fifteen minutes in the calendar to look at Reports.
What "onboarded" actually means
Not "has an account". A team is onboarded when:
- Every critical journey has a test.
- A smoke suite runs on a schedule and someone reads it.
- Anyone on the team can diagnose a red test without escalating.
- New defects get a test as a matter of routine.
- You can state the maintenance share, and it is falling.
The five ways this goes wrong
| Starting with the hardest flow | The twelve-step checkout on day one produces frustration and a conclusion that the tool does not work. Earn a win first. |
| Onboarding everyone on day one | Six people hitting an unconfigured environment simultaneously creates six people who think it is broken. |
| Tolerating flake | The fastest route to a suite nobody reads. Fix causes in week one. |
| Scheduling before anyone owns the result | A nightly suite nobody reads manufactures confidence. Name the owner first. |
| Never writing a skill | You get decent results forever instead of good ones. It is the biggest lever available and it is free. |
When to ask for help
Immediately, on any of these — each is a day you should not spend:
- Studio cannot reach your application after working the access checklist.
- Your application is not on the public internet.
- A flow depends on email, SMS or a third-party system you do not control.
- You want a skill built for your system under test. That is complimentary; ask.
- You have an existing Selenium or Playwright suite to bring across.
Raise a ticket or speak to your Functionize contact. The teams that get value fastest are the ones that ask in week one rather than week six.