This is a picture-by-picture walkthrough of creating your first test in Functionize Studio, from an empty project to a green run. Every screen below is the real product, and the test being built is one you can build yourself against a public demo site. Allow about ten minutes.
If you want the concepts first — what the agents are and how self-healing works — read Getting Started before this one. This article is the hands-on version.
What you need
- A Functionize Studio account, signed in at
studio.functionize.com. - A site to test. This walkthrough uses
https://www.saucedemo.com, a public demo shop whose test credentials are printed on its own login page. Use it if you want to follow along exactly; use your own application if you would rather.
Nothing to install. Tests run on our infrastructure, in a real browser.
Step 1 — Make a project to keep the work in
Projects group related tests. From Projects in the left sidebar, choose New Project, give it a name, and open it. A new project looks like this:
The empty state tells you what the product is for: describe what you want to test in plain language, Studio writes the test, runs it in a real browser, and shows you what passed. That is the whole loop, and the rest of this article is that loop happening once.
Step 2 — Describe the test
Click New test. A panel opens on the right asking you to describe what you want. You are not writing steps here — you are describing an outcome, the way you would brief a colleague.
The description used above was:
Go to https://www.saucedemo.com and log in with the demo account standard_user / secret_sauce that is published on that page. Verify the Products page appears, add the Sauce Labs Backpack to the cart, and verify the cart badge shows 1 item.
Three things make a description work well:
- Give a starting URL. The agent checks it is reachable before it builds anything.
- Say what a user does, not how the page is built. "Add the Sauce Labs Backpack to the cart" is better than naming a CSS class. Studio finds elements visually and contextually, so describing intent is what lets a test survive a redesign.
- Say what "passed" means. "Verify the cart badge shows 1 item" becomes a real assertion. Without it you get a script that clicks things and never checks anything.
Note the project chip at the bottom of the box — it confirms which project the new test will be created in. Check it before you send, particularly if you keep several projects open.
Step 3 — Review the instructions before anything is built
Studio does not jump straight to building. It turns your paragraph into a numbered set of instructions and shows you them first:
This is the cheapest moment to correct a misunderstanding, so read it properly. If the agent has misread you, say so in plain language — "don't log in, the cart should work signed out" — and it will redraft. When it looks right, reply Yes, create it.
This review step is also the honest answer to "how do I know it understood me?". You are not guessing; you are approving a plan.
Step 4 — Watch it build
Studio starts a background agent and narrates what it is doing as it goes: assessing the starting URL, resolving the environment, then generating and checking each step against the live page.
The card with the Test chip is the background agent. You can keep working while it runs. When it finishes it tells you the test ID and the project it landed in.
Generation usually takes somewhere between thirty seconds and a couple of minutes, depending on how many steps your description implies and how quickly the site under test responds.
Step 5 — Read the test editor
When generation completes you land in the test editor. It is three panes, and knowing what each one is for makes the rest of the product obvious:
- Left — the agent. The conversation that built this test, and where you ask for changes. It stays with the test, so the reasoning behind a step is still there weeks later.
- Middle — the steps. Your instructions, numbered, colour-coded by result.
- Right — the browser and the data. A screenshot of the page at the selected step, and underneath it the values that step read.
In the example above, four instructions became eleven steps, and the summary reports 11 of 11 steps passed on Chrome. That expansion is normal: "log in" alone is seven steps once you count loading the page, focusing each field, typing, submitting and landing on the next page.
If you would like the guided version of this screen, the product has a built-in tour that labels each pane:
Step 6 — Open a step and see what it actually did
Click any step to expand it. Instruction 3, "Add the Sauce Labs Backpack to the cart", contains a single action:
Two things are worth noticing here.
First, the action reads Click BUTTON element with TEXT 'Add to cart' — a
description of the element, not a brittle selector path. That is what lets the step keep working
when the page around it changes.
Second, the right-hand pane shows the page as it was at that moment, with the matched element outlined. Below it, the Data tab compares three columns: Previous Successful Run, Current and Generated. When a test starts failing, that comparison is usually where the answer is — you can see what the value used to be and what it is now.
The other tabs are Log, Extension, Variables and Components Model.
Step 7 — Run it
Choose a browser from the selector at the top, then click Run Test. Studio boots a clean runtime host and executes the test there — not in your browser, so you can close the tab if you want.
While it runs you can watch the steps turn green in order, with the live page beside them:
When it finishes, the header shows when the run happened and the step list carries the result.
Where the test lives now
Back in the project, your test is listed with its status, when it was last updated, when it last ran, and which browsers it has run on:
From here you can filter by tag, creator, browser or status once you have more than a handful, and select several tests at once to run or organise them.
When a step does not pass
It is worth showing what happened during the real run above, because it is the normal case and not a failure of the product.
While generating the last instruction, the agent read the cart badge and got an empty value rather than "1" — the badge had not rendered yet at the instant it looked. Rather than baking a broken assertion into the test, it said so in the transcript, confirmed visually from the screenshot that the badge did show 1, and bound the verification correctly. The finished test then passed eleven of eleven steps.
That is the pattern to expect: the agent tells you what it was unsure about, in the transcript, at the time. When a step genuinely fails later, the same three places give you the answer — the step's screenshot, the Data comparison, and the agent, which you can simply ask.
You can type a question straight into the chat on the left. "Why did step 4 fail?" is a reasonable thing to ask it, and it has the run in front of it.
What to do next
- Ask the agent to add a case to the same test — "also check that the cart page lists the Backpack at $29.99".
- Group tests into an Orchestration to run them together on a schedule.
- Connect your own AI tool to Functionize over MCP, so you can create and check tests from your editor. See Getting Started with the Functionize MCP Server.
- Ask us to build a skill for your application, so the agent starts out knowing your domain rather than discovering it. See Complimentary Skill Building for Your System Under Test.
If something in this walkthrough does not match what you see, the product has moved on and we would like to know — raise a ticket and we will correct the article.