Silent failures and stale screens: testing what the page does not say
Some bugs leave nothing on the screen: a request fails and no message appears, or the page confirms an order that was never saved, or the total next to the quantity is the one from a minute ago. A tester who reads only the screen passes all of them. This guide is about where else to look after each action, and which inputs get there.
Three places to check after every action
After each click that is supposed to do something, there are three things to read: what the screen says, what the server answered, and what is stored now. The bug is wherever they disagree.
The setup is short. Open the browser's developer tools, go to the Network tab and turn on "Preserve log" so a page reload does not wipe it; keep the Console tab within reach. From then on, every submit leaves a status code and a response body you can read, whatever the page chose to show.
Failures with no message
| What you see | Where to look | What is there |
|---|---|---|
| The button does nothing | Network tab, status of the last request | A 400 or 500 that the page has no code to display |
| A spinner that never ends | Network tab, then Console | A request that never returned, or a script error thrown before the result was drawn |
| "Thank you" with no order number | Response body | An error in the body of a 200 response, shown as success because the page checks only the status |
| Nothing at all, the field looks fine | Network tab: was a request sent? | The page's own validation rejected the value and forgot to say so |
The inputs that get there are the ones the page and the server check differently. Capital letters in an email address, a plus sign, a space at the end of a code: the page lets them through, the server rejects them, and nobody wrote the branch that shows the rejection. The email field guide lists the addresses worth sending. A 500 on any value you typed is a bug even when the screen stays calm; reproduce it once more after a reload before writing it up, because a stale page produces the same picture.
Success that did not happen
The mismatch runs the other way too: the page says saved, and nothing was. After a confirmation,
reload the page and find the record in the list, or log in with the
account that was just created, or ask the API for the item by its id. A page that decides on the
status code alone will show success for a 200 whose body says {"error": "..."}, and the
only way to see that is to read the body.
Stale screens
A stale screen shows a state that was true a moment ago.
- An error message that stays after the problem is fixed. Correct the field, then look: the message should go, with no second submit. If it stays, the form looks still broken.
- An old confirmation next to a new error. Place an order, then make one that fails. Is the earlier order number still on screen, now beside the error?
- A total computed before the last change. Calculate, change the quantity, place the order without calculating again. The checkout total guide covers what should happen.
- A deleted item that still counts. Delete something, then try to take its place: its time slot, its username, its email. A record that is marked deleted but still blocks what it held is hard to see because the list no longer shows it.
- A list that did not refresh. Change an item in a second tab and come back to the first.
The pattern behind these tests: do an action, then one that contradicts it, and read the whole screen again.
What to put in the report
A silent failure gives nothing to screenshot, so the report carries the request instead: method,
path, status, the response body with personal values replaced, and the exact input. "Place order does
nothing for an address with capital letters; POST /orders returns 500, body
{"error":"internal"}, with [email protected] as the email" gives the developer
a request to look at. A report that says the button sometimes does not work has none of that, and the
first reply to it is a question.
How often these get missed
When three AI agents ran the practice exercises on this site in October 2026, the bugs that stayed unfound in every run that had them were of this kind: an order that fails on the server with no message, data written to the browser console, a value the server accepts from the browser without recomputing it. Most runs filled fields from scripts and read what the page showed back. The numbers are in what AI testing agents find and miss.
Open the practice form
More guides: email fields · what the server trusts · all guides