User Flow Tester: scenario E2E tests
Describe key user operations as steps — sign-in, checkout, search — and get ready Playwright tests that refuse to run on production. The tool checks the flows against published rules, shows route coverage and reads your run report.
Free, no sign-up
Scenarios
How the tool works
Flows built from steps
A scenario has a name, tags, a critical flag, a start route, a device view and a sign-in note. Steps are navigation, actions, waits and assertions. Elements are found the way the Playwright docs recommend: by role and name, field label or test id.
Rule-based checks
Each finding is a rule with an ID, a level and evidence: a fragile selector, a flow without a final assertion, a plain-text password, a fixed-time pause. Steps with errors are not generated — a comment with the rule ID takes their place.
Playwright Test code
One tests/e2e/<scenario>.spec.ts file per scenario, a readable test.step per step, @critical in the title, screenshots on named steps. Plus playwright.config.ts with traces on retry, screenshots on failure, CI retries and list, html and json reporters.
Coverage and results
Paste a route list or sitemap.xml and mark the critical routes — the tool shows which ones no scenario opens. After a run, load the JSON report: statuses, durations, errors, attachments, flaky tests and a comparison with the previous run.
Go to page
- Group
- navigation
- Needs an element
- —
Click
- Group
- action
- Needs an element
- yes
Fill field
- Group
- action
- Needs an element
- yes
Select option
- Group
- action
- Needs an element
- yes
Check
- Group
- action
- Needs an element
- yes
Uncheck
- Group
- action
- Needs an element
- yes
Press key
- Group
- action
- Needs an element
- optional
Hover
- Group
- action
- Needs an element
- yes
Wait: text visible
- Group
- wait
- Needs an element
- —
Wait: URL
- Group
- wait
- Needs an element
- —
Wait: server response
- Group
- wait
- Needs an element
- —
Expect: visible
- Group
- assertion
- Needs an element
- yes
Expect: hidden
- Group
- assertion
- Needs an element
- yes
Expect: text contains
- Group
- assertion
- Needs an element
- yes
Expect: URL matches
- Group
- assertion
- Needs an element
- —
Expect: page title
- Group
- assertion
- Needs an element
- —
Expect: count
- Group
- assertion
- Needs an element
- yes
Screenshot
- Group
- other
- Needs an element
- —
Fixed-time pause (forbidden)
- Group
- other
- Needs an element
- —
Guard against running on production
- The target comes only from the STAGING_URL variable; steps use root-relative paths (/catalog), and absolute URLs are forbidden by rule UFT-T13.
- playwright.config.ts stops before the first test if STAGING_URL is missing, is not an http(s) URL, matches a production host or is not on the staging allow-list.
- Passwords, tokens, PINs and card data come from environment variables (env:NAME → process.env.NAME). A literal that looks like a secret is never written to code (UFT-T06, UFT-T07).
- Run commands are in the README: npx playwright install, then STAGING_URL=… npx playwright test --grep @critical.
Check rules
The table is generated from the same code as the checks in the tool.
UFT-P01
- Level
- error
- Rule
- No staging host is listed
- What to do
- Add the staging host to the allow-list — without it the config stops every run.
UFT-P02
- Level
- error
- Rule
- A host is listed as both staging and production
- What to do
- Remove the production host from the staging allow-list.
UFT-P03
- Level
- warning
- Rule
- A line does not look like a host
- What to do
- Enter a host without a path: staging.example.com or localhost:3000.
UFT-S01
- Level
- error
- Rule
- The scenario never navigates
- What to do
- Set a start route or add a “Go to page” step.
UFT-S02
- Level
- error
- Rule
- Duplicate scenario name
- What to do
- Names must differ: run results are matched to scenarios by name.
UFT-S03
- Level
- warning
- Rule
- The scenario does not end with an assertion
- What to do
- End with an “Expect…” step — otherwise the test passes even when the outcome is wrong.
UFT-S04
- Level
- warning
- Rule
- A field is filled but nothing is checked afterwards
- What to do
- Add a check of the outcome after the input (URL, text, message).
UFT-S05
- Level
- error
- Rule
- The scenario has no steps
- What to do
- Add at least one action and one assertion.
UFT-T01
- Level
- error
- Rule
- A required step field is empty
- What to do
- Fill in the field — the step is not generated without it.
UFT-T02
- Level
- warning
- Rule
- A CSS selector instead of a role, label or test id
- What to do
- CSS breaks when markup changes. Use a role and name, a field label or a data-testid.
UFT-T03
- Level
- warning
- Rule
- An XPath selector
- What to do
- XPath is tied to the DOM structure. Replace it with a role, label or test id.
UFT-T04
- Level
- warning
- Rule
- Position-based selection (nth-child, nth, eq)
- What to do
- Element order changes. Find the element by name or test id.
UFT-T05
- Level
- error
- Rule
- Fixed-time pauses are forbidden
- What to do
- Replace the pause with a wait for text, URL or server response — no code is generated for a pause.
UFT-T06
- Level
- error
- Rule
- The value looks like a secret
- What to do
- Use env:NAME — the value will come from an environment variable. The literal is not written to code.
UFT-T07
- Level
- error
- Rule
- A password or code is written into the scenario
- What to do
- Use env:NAME for passwords, tokens, PINs and card data. The literal is not written to code.
UFT-T08
- Level
- error
- Rule
- Invalid environment variable name
- What to do
- Use upper-case Latin letters, digits and _: env:E2E_USER_EMAIL.
UFT-T09
- Level
- tip
- Rule
- Clicking by text rather than by role
- What to do
- A role with a name is more precise: the “Sign in” button will not match a paragraph containing “Sign in”.
UFT-T10
- Level
- warning
- Rule
- A role without an accessible name
- What to do
- Without a name, several elements usually match the role — the test fails in strict mode.
UFT-T11
- Level
- warning
- Rule
- A response wait is not placed before an action
- What to do
- Put “Wait: server response” right before the action that sends the request — the generator combines them.
UFT-T12
- Level
- error
- Rule
- Unknown key
- What to do
- Examples: Enter, Tab, Escape, ArrowDown, Control+A.
UFT-T13
- Level
- error
- Rule
- An absolute URL instead of a path
- What to do
- Use a root-relative path (/catalog): the host comes from STAGING_URL and passes the production guard.
UFT-C01
- Level
- warning
- Rule
- A critical route is not covered
- What to do
- Add a scenario that opens the route or asserts navigation to it.
Limitations
- Generated code is a starting point: button names, field labels and routes must match your UI. Run the tests on staging and fix steps that did not find an element.
- The sign-in state is a note: the tool does not create storageState files or auth fixtures.
- Route coverage counts only navigation and URL assertions in scenarios; following a link without asserting the URL does not count.
- Only attachment names and paths are read from the report — screenshots and traces are not loaded. Tests are matched to scenarios by name (without tags) or file name.
- A green run does not guarantee there are no bugs: tests check only what they describe.
Privacy
- Scenarios, routes and reports are processed in your browser and are not sent anywhere on their own; the page address does not change.
- The draft and versions are stored only in this browser (localStorage); “Clear all” deletes them. Imported runs are stored in a reduced form — without attachment bodies.
- Analytics receives only the fact of an export or import and a category (file type, whether anything failed) — no names, steps or URLs.
- The result reaches us only if you send a request yourself and keep the “Attach the result” box ticked — the form shows exactly what will be sent: scenarios with steps, route coverage and the last run's totals. Staging and production hosts, field values, error texts and attachments are never included.
Related tools
All tools · 40
Release readinessAn evidence-backed check matrix: CI, migrations, backups, a rollback plan, monitoring, risk exceptions and sign-off → a GO / NO-GO decision.
Screenshot → Bug reportA screenshot or video → private data hidden, the problem marked up, reproduction steps, a human check and export to GitHub, GitLab or Jira.
API Mock StudioImport OpenAPI or define endpoints → test data, different HTTP responses, delays and errors, a request log, contract checks and a ready mock server.
UI consistency checkerDesign tokens vs CSS: off-system colours and sizes, WCAG contrast, screenshot comparison against an approved baseline, and triage.
MVP validation toolkitHypotheses with thresholds, a landing page and lead form, UTM links, a funnel, interviews and an experiment report → continue, pivot or stop.
Proposal builderProposal templates for IT projects: scope, phases, estimate, timeline, assumptions and exclusions, versions with number control, approval and PDF.Want your tests and release process audited?
We check which user operations are protected by tests, where tests are fragile and what makes releases risky. Scope and cost come after a short brief.
- The first short conversation is free — we choose the format
- NDA — yours or ours
- Pricing after a brief and an agreed scope