TL;DR: Yes: describe the flow you care about in plain language, such as 'create a project', and TaloTrace explores your running app, drives that journey to a verified outcome, and turns it into a replayable test. No test script to write. The caveat: destructive actions are held back, and some capability, like the device matrix, is plan-gated.
Key Takeaways
Plain language in: describe the flow you care about and TaloTrace explores your running app to find and complete it, no test script required.
Proof, not assumption: a goal only counts as done when a machine-checkable predicate proves the outcome, false before and true after.
Sight-based navigation: TaloTrace drives your app by looking at the screen, so it keeps working when the UI changes.
Independent review: TaloTrace checks each finding before it reaches you, and results stay hidden until a reviewer approves them or the project is set to auto-approve.
Real limits: destructive actions are held back, the device matrix is plan-gated, and runs start on demand or on a schedule, not from a pull request.
Can You Describe a User Flow in Plain English and Get It 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 a replayable scenario.
Plain-English test authoring is the practice of describing a user flow in everyday language, such as 'create a project', and letting the testing tool work out the steps and verify the result, instead of writing a test script.
There is no test script to write. If you would rather not describe anything at all, 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 Trying to Skip by Not Writing Test Scripts?
Skipping test scripts usually means skipping two costs: the engineering time to write and maintain them, 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 problems, because TaloTrace plans and drives the journey itself rather than replaying steps you scripted in advance.
How Does TaloTrace Turn a Plain-English Description Into a Test?
TaloTrace explores your running app, using your product documentation, saved test accounts and the 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 also 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, rather than crossed. 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.
It navigates by looking at the screen rather than relying on brittle element IDs, which is how it keeps working when your UI changes. The mechanics are covered in why sight-based tests keep working after UI changes. A goal only counts as complete once a machine-checkable predicate proves the outcome was false beforehand and true afterward, so a screen that already shows 'Projects' cannot accidentally pass a 'create project' goal. Completed journeys become scenarios in a Test Plan you can rerun on demand or on a schedule.
How Does TaloTrace Get Into Your App to Run It?
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: it is stored for future runs but never sent back out, and it is 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 the code and enter it automatically. 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 Do You Get Back After TaloTrace Tests a Flow?
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 separates finding an issue from reporting it: it independently reviews each finding before it reaches you, and nothing you see is the raw, unchecked output of the step that found it. 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 sit outside that and 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, alongside its internal code. You can supply your own severity guidance, and TaloTrace rates findings against it.
What Are the Limits of Testing a Flow This Way?
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.
Area | Supported today | Not supported or limited |
|---|---|---|
Platforms | Browser, Android emulator, iOS Simulator (cloud-hosted) | Physical devices |
Starting runs | On demand from the app or API, or a daily or weekly schedule | Pull-request triggers |
Sign-in | Email and password, plus free-text steps like an OTP prompt | Password-less or SSO-only login |
Actions | Create, save, submit | Destructive actions like deleting an account or making a payment |
Device matrix | Several device or OS configurations in one submission | Plan-gated: the free trial runs the default profile only |
Sign-up gates | Emailed or texted one-time codes, best effort | Account state across sessions, like renewals or trial expiry |
There is no pull-request trigger today, so a scheduled run always tests whatever build you shipped most recently rather than a specific commit. For a worked example of one flow end to end, including how the payment step is held back, see how to test a checkout flow without writing a test script.
What Makes TaloTrace's Plain-English Testing Different?
TaloTrace pairs plain-English input with proof of completion and independent review on the same run. A goal is only marked done when a machine-checkable predicate is false before the action and true after, so an unverified journey fails instead of reporting a pass.
TaloTrace also checks its own output before you see it, holding results behind review by default rather than surfacing every raw observation. Combined with sight-based navigation that keeps working as your UI changes, that is how TaloTrace proves what happened rather than only describing what it tried. Read more about the thinking behind this on our why page.
How Do You Start Testing a Flow with TaloTrace?
Beta is open now. Apply for early access. Most pricing tiers are published and can be set up directly from the pricing page, with custom terms available at enterprise scale.
Frequently Asked Questions
Do I need to write any code or test scripts to use TaloTrace?
No. You point TaloTrace at your app and, if you want to steer it, describe the flow you care about in plain language. TaloTrace explores the app, plans the journeys worth testing, and turns completed journeys into replayable scenarios; scenarios can also come from a chat description or be written by hand.
How does TaloTrace know when a test has actually passed?
A goal is marked done only when a machine-checkable predicate proves the outcome: false before the action, true after. A scan that produces no independently proven goal fails rather than reporting an unverified journey as a pass.
Can TaloTrace log into my app to run the flow?
Yes. You save the test accounts TaloTrace should use, each with a role label such as admin or viewer, and TaloTrace signs in with email and password. Free-text instructions can cover an extra step, like an OTP prompt or a second screen.
What does TaloTrace do with destructive actions, like deleting an account?
It holds them back. Destructive or irreversible actions, like deleting an account or making a payment, are not performed. Everything else, such as create, save and submit, is committed for real, and TaloTrace reads the resulting screen to confirm what changed.
Does this work on mobile apps as well as web apps?
Yes. TaloTrace runs on three cloud-hosted virtual execution planes: a browser, an Android emulator and an Apple iOS Simulator, chosen automatically from your app's platform. Physical devices are not offered on any of them.
What do I get back after a run?
Each run produces Findings, backed by a screen recording, TaloTrace's reasoning and step-by-step reproduction. Findings carry a severity, following your own rubric if you have supplied one, and results stay hidden until a reviewer approves them or the project is set to auto-approve.
