Describe a User Flow in Plain English, Get It Tested

Can you get a flow tested without writing a script?

Yes. Point TaloTrace at your app and, if you want to steer it, describe the flow you care about in plain language, for example "create a project". TaloTrace explores the running app, plans the user journeys worth testing, drives each one to a verifiable outcome, and turns the journeys it completes into replayable scenarios. There is no test script to write. Scenarios can also come from a chat description, or be written by hand.

For example, if you describe the flow as "create a project":

• TaloTrace signs in with the test account you saved for that role.
• It explores the app to find where projects are created, using any product docs you imported.
• It commits the real actions, such as filling in the form and pressing Save.
• It marks the goal done only if a check that was false before, such as the new project appearing in the list, is true after.
• The completed journey becomes a replayable scenario in your Test Plan.

What are you skipping by not writing scripts?

Usually two costs: the engineering time to write and maintain scripts, and the brittleness of scripts tied to element IDs that break when the UI changes. Without a QA engineer on staff, writing scripts can be a barrier of its own. Describing a flow in plain language sidesteps both, because TaloTrace plans and drives the journey itself rather than replaying steps scripted in advance.

How a description becomes a test

TaloTrace uses your product documentation, saved test accounts and the running app itself to work out what a flow like "create a project" actually involves. Docs can be pasted in directly or imported from Confluence or Linear, and re-importing refreshes them in place instead of duplicating them.

You can set boundaries TaloTrace stays inside. A flow that would cross one is recorded as blocked, with a note on what would be needed to test it safely. Within those boundaries, TaloTrace commits real actions, such as create, save and submit, and reads the resulting screen to confirm what changed; only destructive or irreversible actions, like deleting an account or making a payment, are held back.

TaloTrace navigates by looking at the screen rather than relying on brittle element IDs, which is how it keeps working when your UI changes. Completed journeys become scenarios in a Test Plan you can rerun on demand or on a schedule.

How TaloTrace gets into your app

You save the test accounts TaloTrace should use, once per project, each with a role label such as admin or viewer. Sign-in is email and password, and you can add free-text instructions for logins that need an extra step, like an OTP prompt or a second screen; those instructions are additive to a password, since there is no password-less or SSO-only path today.

A saved password is write-only: stored for future runs, never sent back out, and masked out of the run's captured steps and logs. For apps that gate sign-up behind an emailed or texted one-time code, TaloTrace can use a throwaway inbox or number to receive and enter the code. Treat that as a best-effort way through a sign-up gate, not a guarantee, and not as persistence of a session or account across runs.

What you get back: a Trace

A completed run produces a Trace: a set of findings, each backed by a screen recording, TaloTrace's reasoning and step-by-step reproduction, including an Evidence panel showing the steps it took. A vision model also analyses the recording itself, so visual and functional anomalies can surface even when nothing hard-fails.

TaloTrace independently reviews each finding before it reaches you. Results start hidden and only become visible once a reviewer approves them, or once a project is explicitly configured to auto-approve; low-confidence findings need an individual decision to release. Repeated observations of the same defect collapse into a single issue, and severity is shown as one of five levels, from Critical to Trivial. You can supply your own severity guidance, and TaloTrace rates findings against it.

What are the limits?

TaloTrace runs on three cloud-hosted virtual execution planes, a browser for web apps, an Android emulator and an Apple iOS Simulator, chosen automatically from your app's platform.

There is no pull-request trigger today, so a scheduled run always tests whatever build you shipped most recently rather than a specific commit.

What makes this different?

TaloTrace pairs plain-English input with proof of completion and independent review on the same run. An unverified journey fails instead of reporting a pass, results are held behind review by default rather than surfacing every raw observation, and sight-based navigation keeps working as your UI changes. That is how TaloTrace proves what happened rather than only describing what it tried.