Write a user journey

A user journey is a flow through your site that Zof's end-to-end test runs in a real browser, step by step: open a page, click, fill in a field, then check what the page shows. You write it in a short step language, one step per line.

Writing a short journey takes about 5 minutes. Zof only understands the steps below. Free text such as "open my about page" can't be run, and the run shows Couldn't check (Journey needs rewording).

Where to write it

On Runs, choose Run tests, then tick End-to-end test in the Test types step. The Options step shows User journeys: type each journey's steps in its box, one per line. Choose Add a journey for another. See Run a test for the other steps.

The step language

Quoted text names something on the page, or a value to type. Everything else is a fixed word from this table.

Rules

• One step per line.
• Quoted text names things on the page or values to type, for example click link "Pricing".
• A journey has at most 30 steps, and a run has at most 5 journeys.
• Stay on your address: open a path such as /about-us, never a full address on another site. If the first step isn't open, the journey starts at the address you're testing.
• Each journey starts in a fresh browser, at desktop size, with no cookies from another journey.
• Steps also find controls inside frames from your address. A control inside another site's frame is never used.

Tips

• Use link or button text that appears once on the page. A step that matches more than one visible control is ambiguous and cannot run safely. Naming the kind of element helps: click link "Get started" only looks at links; give it a unique accessible name if several links still match.
• Text checks match whole words and ignore capitals: expect "error" doesn't match "No errors found". Clicks match the whole name, never part of it.
• Don't submit real forms, such as sign-up or subscribe forms: they create real data on your site. Check that the form is there instead.
• Never type an account password into journey steps. Without saved test sign-in, the wizard refuses password steps and account placeholders. When saved sign-in is available, use the mode and placeholders below.
• End with a check, such as expect or expect url. A journey without one passes as long as every step runs. A journey that only opens pages gets a check added for you: that the last page it opened loaded, like expect url /pricing.
• A confirmation message proves only what the page displays. To check that an order was saved, add an explicit supported readback, such as opening a test order page and checking its unique order text. Unsupported business outcomes and control states remain unproven even when the supported steps pass. Each part of an expected outcome counts on its own: in Results show "Dune" and the result count is 2, the count has no quoted text to check, so the run warns "part of an expected outcome not understood" and doesn't count it as checked.

Test sign-in

When saved test sign-in is on, enter the test account email, password and protected page, or use the saved account, in a manual end-to-end run's Options. Signed-in checks starts each journey after verified sign-in. Test sign-in from signed out starts each journey anonymously so its steps can test the ordinary login form. See Run a test to save and select the account.

In Test sign-in from signed out, use fill "Email" with {username} and fill "Password" with {password}, with your form's actual field labels. The saved values are substituted only while the test runs. Never put the username or password themselves into step values. Open the saved login path, fill those fields, submit the sign-in button once, then check the saved protected page or its text shown only when signed in. For example:

open /login
fill "Email" with {username}
fill "Password" with {password}
click button "Sign in"
expect url /dashboard

This supports one username/password form on the saved website address. OAuth, SSO, MFA, CAPTCHA and further form submissions after sign-in are unsupported. A failed or unverified sign-in ends as Couldn't check rather than passing as a public journey. Signed-in journeys do not save screenshots.

A worked example

For a marketing site at https://www.example.com, the first journey checks that visitors can reach the services page from the home page:

open /
dismiss the cookie banner
click link "See how it works"
expect url /services
expect "Our services"

The second checks that the sign-up page opens, without submitting it:

open /
click link "Sign up"
expect url /signup
expect button "Create account"

Check that it worked

When the run finishes, its page lists each journey with the steps it ran. Passed means every step of every journey passed. If any step failed, the run shows Issues found, and the journey shows the step that failed, with a screenshot when a public journey captured one. A step Zof couldn't understand means nothing ran: the run shows Couldn't check.

Common errors and fixes