Search
Features
How individual Functionize Studio features work - self-healing and timing, workflows, extensions and reporting.
-
Projects: Boundaries, Defaults and What Inherits What
A project is the container for tests that share an application, an environment and a set of defaults. It is the least glamorous object in Studio and the one that causes the most trouble when it is drawn badly, because almost everything else inherits fro...
-
The Tests Screen: Finding, Tagging and Fixing Tests at Scale
Every test you or anyone else has built lives on one screen. For the first couple of weeks that screen is a convenience. By the time an account holds a few thousand tests it is the main way anybody finds anything, and the habits you form early decide wh...
-
Test Data: Execution Presets, Variables and Secrets
Tests need data: a price to check against, an account to sign in with, a reference number a later step depends on. Studio keeps that data out of the test itself, so the same tests can run against different environments and so secrets never end up writte...
-
Orchestrations: Running a Suite as One Job
A test tells you about one flow. An orchestration tells you whether the application still works. It is an ordered group of tests that runs as a single job, on demand or on a schedule, with one result and one history. This is the feature that turns a co...
-
Scheduling an Orchestration: The Six Cadences and What Each One Costs
An orchestration's schedule is the single setting that decides what it costs and whether anyone still trusts it in six months. Everything else about a suite — which tests, what order, who gets the email — matters less than how often it runs. There are ...
-
Run Order, Re-runs and Alerts: An Orchestration's Advanced Settings
The New Orchestration panel has four fields you cannot miss and two collapsed sections you easily can. Advanced settings is the second of them, and it holds four decisions that change what a suite does when something goes wrong. None of them are requir...
-
Managing Orchestrations: Filters, Bulk Actions and Run History
Building an orchestration takes two minutes. Living with a few hundred of them is the part nobody writes down. This page covers the orchestrations list — how to find things in it, what you can do to several at once, what each row's menu offers, and what...
-
Execution Presets: Running One Suite Against Different Data
Most teams reach the same wall at about the thirtieth test: the same journey needs proving twice. Once as a guest and once signed in. Once against staging and once against a UAT environment. Once with a US address and once with a German one. The obviou...
-
Self-Healing and Timing: Controlling How Studio Recovers
Studio adapts tests when your application changes — it finds a moved or renamed element instead of failing on a broken selector. How hard it tries, and how long it waits before giving up, are things you control. This article explains those settings, whe...
-
Workflows: Scheduled Jobs Written in Plain Language
A workflow is a recurring job described in plain language and run on a schedule. Where a test proves your application behaves correctly, a workflow just does something in a browser and reports back — checking a competitor's price, pulling a figure off a...
-
Extensions: Running Your Own Code Inside a Test
An extension is a piece of your own code that a test can call mid-run. Most tests never need one. When you do need one, it is usually because a step has to do something a browser cannot: decrypt a token, call an internal API, transform a value, read a f...
-
Reports: Pass Rates, Trends and What They Actually Tell You
Reports answers one question across everything you run: is testing getting better or worse? It is the only screen in Studio that looks across projects rather than at a single test. Open in Studio Open Reports and read along. Links open in a new tab. Rep...