The page returned an error status
Anavigate step reads the response status, so a page that 404s or 500s fails
there rather than three steps later on a confusing assertion.
For
403 and 429, the site is often refusing the automation, not the
request. An environment header or a cookie that identifies the run as yours is
usually the fix.
A dialog appeared
Nativealert, confirm and prompt dialogs are accepted automatically so
they cannot freeze a run, and what appeared is recorded. The step that raised
it and the step after it can both assert on it.
A download did not arrive
A step with a download expectation waits up to 10 seconds for the download event. The file is captured either way; the expectation only decides whether the step passes. If nothing arrived, the click probably did not trigger a download, so check the screenshot for a modal or a validation error in the way.The page moved while the step was starting
Resolution takes time and an app can redirect inside that window. Testorim does not refuse the step: it settles, finds the target on the page the app is now showing, acts, and records the move as a warning naming both addresses. A target that is not on the new page fails naming both.Enter did nothing
Before pressing a submit key, Testorim checks the focused control can actually act on it: a textarea, something with its own activation behaviour, a field inside a form, or an element with a real key listener.- If it can and the page ignored it, the field’s own submit button is clicked instead and the keyboard gap is recorded as a warning. That gap is a real accessibility finding.
- If it provably cannot, the step fails as an app defect: this page is not operable by keyboard here.
- If a key was sent to nothing at all, the step fails rather than reporting a success that never happened.

