Vision Model Catches a Visual Bug That Isn't a Hard Failure

What Are You Actually Trying to Catch?

TaloTrace is a tool that explores your app without test scripts, records every run and independently verifies each finding before it reaches you. This post covers the part that matters when nothing fails loudly: what the vision model looks at and what you get back.

You have a green test run and a screen that still looks wrong. Nothing threw an error and no assertion failed, so a pass/fail result had nothing to report.

That gap is the job here. You want something that looks at what the user would see and flags what seems off, without you having to script a check for each way a screen could go wrong.

Many quality expectations are defined by what a person perceives on screen, not by what code returns. The W3C's Web Content Accessibility Guidelines, for example, set requirements such as text contrast and content reflow that a passing assertion cannot confirm by itself.

How Does TaloTrace Look at Your App?

TaloTrace navigates by looking at the screen, rather than relying on element IDs, so it is less affected when the UI changes. Its interaction range covers:

• Touch: taps, long-press and double-tap
• Movement: scrolling, swiping and drag
• Input: typing and pinch

You point TaloTrace at your app and, optionally, describe the flow you care about most in plain language, such as "complete a checkout". It explores the running app, plans the user journeys worth testing and drives each one to a verifiable outcome. The journeys it completes become replayable scenarios, with no test scripts to write.

A goal is marked done only when a machine-checkable predicate proves the outcome. The predicate must be false before the action and true after, so a screen that already shows "Projects" cannot falsely complete a "create project" goal. You can read more about how TaloTrace works on the how it works page.

What Does the Vision Model Add Beyond Pass/Fail?

A vision model, in this context, is a model that analyses the screen recording of a run for visual and functional anomalies on screen, not only hard failures. TaloTrace captures a screen recording for every run.

That is the part that speaks to your problem. A hard failure is something like a crash or an error. An anomaly is something that looks wrong on screen.

TaloTrace plans its tests using product documentation you import, saved test accounts and the app itself. Documentation can come from:

• text you paste in
• Confluence pages
• Linear issues

That context grounds what TaloTrace tests, and the vision analysis runs over the recording of what happened.

How Does a Finding Reach You?

TaloTrace separates finding a bug from reporting it. It drives your app and records what looks wrong, then independently verifies each finding before it reaches you.

Visibility is fail-closed. Every run's results start hidden, and findings become visible only when a reviewer approves them, or when the project is explicitly configured to auto-approve.

• Low-confidence findings: held separately, and released only by an explicit per-finding decision, never by a run-level approval in bulk.
• Repeat observations: repeated observations of the same defect collapse into a single issue within a run.
• Across runs: a candidate matching an issue TaloTrace already tracks is routed to that issue instead of surfacing as new.

What Do You Get Back From a Run?

A Run produces a set of Findings. Each one is backed by a recording, TaloTrace's reasoning and step-by-step reproduction. The Run detail page includes an Evidence panel showing TaloTrace's step-by-step trajectory.

For a defect that threw no error, the time window matters most. Each finding carries the window inside the recording where the defect shows. Per-scenario verdicts sit alongside it.

Severity has five levels: Critical (P0), High (P1), Medium (P2), Low (P3) and Trivial (P4). You can supply your own severity guidance per project, and TaloTrace follows it when rating findings. Findings land in TaloTrace's built-in issue view.

What Makes TaloTrace Different?

The angle here is the gap between a green result and a wrong screen. TaloTrace explores and tests your app without scripts, records every run, has a vision model analyse the recording for anomalies and independently verifies each finding before it reaches you. What you review is a finding with a time window, not a pass/fail flag.

It has also been dogfooded daily on the Growtrics Academy app, TaloTrace's first and most-tested customer.

It works on web, Android and iOS, all cloud-hosted and virtual. For a closer look at the mobile side, see the post on autonomous mobile app testing.

Where Does This Stop?

Naming the edges makes the rest easier to trust.

• Anomalies are findings, not verdicts: the vision model surfaces what looks wrong on screen. Each finding is independently verified, and a reviewer decides what becomes visible.
• Knowledge import only: Linear and Confluence are used to import knowledge, not to export findings.
• No pull request trigger: runs start on demand from the app or API, or on a daily or weekly schedule. TaloTrace is not a CI check.
• Held-back actions: TaloTrace commits real actions such as Create, Save and Submit, but holds back destructive or irreversible ones, such as deleting an account or making a payment.

A scheduled run is not pinned to a build. It runs the latest finalized build, so a daily schedule keeps testing whatever you shipped most recently.

How Do You Try It?

If your pass/fail suite is green and your screens still look wrong, run TaloTrace against your app and look at what the recording turns up.

Pick the flow you care about most and see what the recording turns up.

Get early access or book a demo