Most testers I have worked with debug by editing the test and running it again. Change a selector, run, wait, fail, change it again. Twenty minutes gone.
Opening the browser's tools first turns that into two minutes. Press F12, or right-click the page and choose Inspect.
Four tabs matter to you.
Elements: the live DOM.
This shows the tree as it exists right now, not the original HTML. Use it for three things.
Click the arrow icon (top left of the panel), then click anything on the page. It jumps to that element in the tree and shows you its tag, its attributes, and its text. This is how you find out whether the button you want has a data-testid.
Watch the tree while you use the app. Open a dialog and you will see new elements appear. This tells you where the dialog actually lives in the tree, which is often nowhere near the button.
Check whether an element is really visible. Hover an element in the tree and the browser highlights it on the page. If nothing highlights, the element has no size or is off screen, which explains a "not visible" failure immediately.
Console: errors and quick experiments.
Red messages here are JavaScript errors from the app. When a page half-loads and your test cannot find anything, look here first. A crashed script explains a missing list better than any selector change.
You can also test a selector before putting it in your test. Type this and press Enter:
document.querySelectorAll('[data-testid="add-to-cart"]')
It returns the matching elements. If you get zero, your selector is wrong. If you get five, your selector is ambiguous and your test will act on the wrong one. Ten seconds here saves a long debugging session later.
Network: what the app asked the server.
Every request the page makes appears here, with its address, its status code and how long it took. Click one to see exactly what was sent and what came back.
This is how you tell apart two failures that look identical on screen. The save button did nothing because the app never sent the request, or the app sent it and the server answered 500. Same blank screen, completely different bug, and the screen alone cannot tell you which.
Application: where the browser keeps state.
Cookies, localStorage and sessionStorage live here. This is where a logged-in session is usually stored, which is why it matters for authentication tests. If a test unexpectedly starts logged out, this tab tells you whether the session was ever saved.
Use these before you touch your test. A failing test raises a question about the app, and these four tabs answer it directly.
Remember this: check the selector in the Console and the request in the Network tab before you rewrite anything.
Reference: Chrome DevTools documentation.