TL;DR: If TaloTrace, an AI powered QA testing tool, skipped an account deletion step mid test, that's expected behaviour, not a bug. TaloTrace holds back destructive or irreversible actions like deleting an account or making a payment, and only marks a goal complete when it can prove the outcome actually happened.
Key Takeaways
By design: TaloTrace commits real actions such as Create, Save and Submit, but holds back destructive or irreversible ones like deleting an account or making a payment.
Boundaries you set: you can also declare boundaries TaloTrace stays inside, and a flow that would cross one is recorded as blocked rather than pushed through.
Proof before pass: a goal is only marked done when a machine-checkable predicate proves the outcome, so an action that wasn't performed isn't reported as a pass.
Evidence either way: every run captures a screen recording, and any finding carries the exact time window where something needs your attention.
Checked before it reaches you: TaloTrace independently reviews each finding before it becomes visible, rather than showing you raw, unverified output.
Is a Skipped Account Deletion Step a Bug?
No. When TaloTrace runs a test plan against your app, it commits real actions such as Create, Save and Submit, and reads the resulting screen to confirm what changed. Deleting an account and making a payment are the named exceptions: TaloTrace holds those actions back rather than completing them for real.
So if your test plan called for account deletion and the run stopped short of it, that's the product behaving as intended. It isn't a missed step, and it isn't a sign that TaloTrace failed to find the button.
What TaloTrace Holds Back, and Why?
A destructive action is one TaloTrace can't safely reverse on a later run, such as deleting an account or completing a payment.
The two examples the product names are account deletion and payment. Both share the same property: once completed for real, there's no later scan that puts things back. A created project can sit there harmlessly. A deleted account can't be undeleted by the next run.
That's the line TaloTrace draws. Actions it can perform and then verify, it performs. The two actions that would permanently change your data or your money — deleting an account and making a payment — it doesn't.
Action type | Does TaloTrace perform it? |
|---|---|
Create, Save, Submit | Yes, and verifies the resulting screen |
Account deletion | No, held back by default |
Payment | No, held back by default |
A boundary you declare yourself | No, recorded as blocked with a note on what would be needed to test it safely |
How Does TaloTrace Decide What to Test Versus What to Leave Alone?
Held-back destructive actions are the default, but you also get a second layer of control. You can declare boundaries that TaloTrace stays inside while it explores your app and plans the journeys worth testing.
A flow that would cross a declared boundary is recorded as blocked, with a note on what would be needed to test it safely, rather than TaloTrace crossing it anyway. That's separate from, and in addition to, the built-in protection around actions like account deletion.
Why Isn't a Deletion Goal Marked as Passed?
TaloTrace only marks a goal done when a machine-checkable predicate proves the outcome: the predicate has to be false before the action and true after. A screen that already shows the expected end state can't falsely complete a goal.
That rule cuts both ways. A scan that produces no independently proven goal fails, rather than reporting an unverified journey as a pass. If your test plan's goal was account deletion, holding that step back means it won't be reported as proven complete either, because it wasn't performed.
What Do You Get When a Step Is Skipped?
The reporting side of TaloTrace works the same regardless of what a given scenario did or didn't complete. Every run captures a screen recording, and a vision model analyses it for visual and functional anomalies, not only hard failures.
If something about the flow is worth flagging, the finding carries the time window in the recording where it shows, alongside TaloTrace's reasoning and step by step reproduction. Severity follows five levels, Critical, High, Medium, Low and Trivial, and you can supply your own rating guidance for TaloTrace to follow when it rates findings.
What Makes TaloTrace Different?
This protection isn't a separate safety switch layered onto a generic test runner. It's built into how TaloTrace decides a goal is done at all: sight-based navigation with no scripts to write, a provable outcome before anything is marked complete, and a check before you ever see a result.
TaloTrace separates finding an issue from reporting it. It drives your app, records what looks wrong, and independently reviews each finding before it reaches you, so nothing you see is the raw, unchecked output of the step that produced it. Results also start hidden by default: findings become visible once they're approved, or once a project is explicitly configured to auto-approve them.
Where Does This Protection Stop?
The built-in holdback covers the two named cases: deleting an account and making a payment. It isn't a general list of every sensitive action your app might have, so if there's another flow you don't want touched, declare it as a boundary yourself rather than assuming it's covered automatically.
Severity guidance works the same way. You can supply your own rubric for how TaloTrace rates findings, but the five severity labels themselves aren't something you can rename or restructure.
How Do You Get This for Your Own App?
TaloTrace's plans and credit bundles are published, and most are available to buy directly. See the current pricing ladder for what each tier includes; enterprise terms are handled separately, through a conversation with the team rather than a self-serve page.
If you want to see how the held-back destructive actions and the boundary system behave against your own app before deciding, apply for early access and try it against a real test plan.
Frequently Asked Questions
Does TaloTrace ever delete a real account or process a real payment during a test?
No. Those are the two destructive actions TaloTrace holds back by default, alongside any additional boundaries you declare for your own app.
If a deletion step is skipped, will the scenario still show as passed?
No. TaloTrace only marks a goal complete once a machine-checkable predicate proves the outcome happened. An action that was held back can't be proven complete, so it isn't reported as a pass.
How do I know a flow was intentionally held back rather than something going wrong?
For boundaries you've declared yourself, TaloTrace records the flow as blocked and notes what would be needed to test it safely. The recording and findings for the rest of the run are still there for you to review.
Can I add my own boundaries beyond account deletion and payments?
Yes. You can declare boundaries that TaloTrace stays inside while it explores your app, on top of the built-in protection around destructive actions.
Does TaloTrace perform any real actions, or does it just look at the screen?
It performs real actions. TaloTrace commits things like Create, Save and Submit and reads the resulting screen to confirm what changed. It only holds back the destructive and irreversible ones.
