Your First 30 Minutes with Functionize Studio

The single biggest predictor of whether a team sticks with Studio is whether the first half hour produces something real. This page is that half hour, deliberately sequenced so you get a passing test before you have to make any decisions.

Minutes 0–10: get one test passing on a site you do not own

Yes, really. Before pointing Studio at your own application, run the loop once somewhere with no login, no VPN and no surprises. You are learning the product, not testing your product.

Use our demo store. Create a project, click New test, and paste this:

Go to https://ecom.functionizeapp.com/testsites/anaqa/index.php?route=common/home and open the Electronics > Laptops category. Verify the Laptops page lists exactly 2 products, and verify one of them is the Vostro 3458 Dell laptop priced at $175.00. Do not sign in.

Approve the plan it drafts, let it build, and run it.

Why this matters: when you later hit a problem on your own application, you will know what "working" looks like. Without that reference point, every wrinkle looks like a product defect.

The full version, with screenshots, is Your First Test in Functionize Studio.

Minutes 10–15: read what you just made

Do not skip this. Open the test and look at four things:

1. The instruction-to-step expansion. Your three sentences became roughly twice as many steps. Whole numbers are your instructions; decimals are the actions Studio generated.
2. A step's action wording. It describes the target — the element containing this text — not a CSS selector. That is the whole reason these tests survive redesigns.
3. The screenshot beside the selected step, with the matched element outlined.
4. The Data tab — Previous Successful Run, Current, Generated.

Five minutes here saves hours later, because these four things are how you diagnose everything from now on.

Minutes 15–20: break it on purpose

This is the step people skip, and it is the one that builds trust. In the test's chat, ask:

Change the price check to expect $999.00 instead, and re-run the test.

Watch it go red. Now read the Execution Error: it names the comparison operator, the value it expected and the value it actually found.

Then put it back:

That was wrong - restore the correct price and re-run to confirm it passes.

You have now seen a failure and fixed it. When a real one happens in week three, it will not be a mystery.

Minutes 20–30: one test against your own application

Now, and only now. Pick the easiest meaningful flow you have — something that loads a page and shows data, ideally without a login.

Write it the same way: a starting URL, what a user does, and what should be true at the end.

If it cannot reach your application, stop and read Before You Point Studio at Your Own Application. That is an environment problem, not a testing problem, and no amount of rephrasing will fix it.

If it reaches the app but the test is wrong, that is usually the description. Say what a user does, not how the page is built.

What good looks like after 30 minutes

• One passing test on the demo store.
• You have seen a red test and read its error.
• One test attempted against your own application.
• You can explain what a project, a test and a session are.

That is a genuinely good first session. If you have it, you are ahead of most teams.

The three habits to carry forward

Describe outcomes, not mechanics. "Add the item to the basket and verify the total" beats any description of the DOM. If you catch yourself writing about elements, stop and rewrite as a user story.

Always say what "passed" means. A test with no assertion cannot fail for the reason you care about. This is the difference between automation that protects you and automation that just moves the mouse.

Read what the agent says back. It shows its plan before it builds and flags contradictions rather than guessing. Skimming past that is how people end up with a test that does not do what they meant.

What not to do in week one

• Do not start with your most complex flow. A twelve-step checkout with test data dependencies is a week-three task.
• Do not build forty tests before running any of them. Build one, run it, learn, then build more.
• Do not put real credentials in a prompt. See Test Data: Execution Presets, Variables and Secrets.
• Do not set a schedule yet. A scheduled suite nobody reads is worse than no suite.

Next

1. Before You Point Studio at Your Own Application — the setup that prevents most first-week failures.
2. Choosing What to Automate First — which flows, in what order.
3. The exercise series — seven short exercises, each with a printable lab handout.