A test broke after a UI change

Every acting step remembers how to find its element. When the markup changes, that memory can go stale, and the step fails with an element that could not be found. This is the most common kind of test maintenance, and it is usually a two minute fix rather than a re-record.

1234

1. 1Replay the single failing step to reproduce the problem quickly.
2. 2Edit the step and update its selector.
3. 3Or delete it and re-record just that one interaction.
4. 4The live browser lets you confirm the element is really there before blaming the test.

Confirm it is the selector

Look at the failing step’s screenshot. If the page looks right and the element is plainly visible, the selector is stale. If the page looks wrong, empty, or shows an error, the problem is upstream and you should look at the step before it instead.

Fix the one step

Open the test in the recorder, start a session, and use replay on the individual step to reproduce the failure quickly. Update the selector, or delete the step and re-record just that interaction. Re-recording the entire journey to fix one click is almost never necessary and throws away edits you have made since.

Make it not happen again

Selectors built on generated class names break every time the CSS is rebuilt. The durable fix lives in your own codebase: add a stable data attribute to the elements your critical journeys depend on, and target that. It is a small change that turns a recurring maintenance chore into a one-off.