A search found one button. The screen found the bug

Our working notes carry a rule about the back office: the easy count is not an audit. The file that builds those screens has around 390 places where a button ends up writing to the server and 57 places where a button is disabled, and that ratio is not a finding, because a matcher cannot tell a button from a helper that a button calls. The note says the office needs a real walk of its screens. This is what the first steps of that walk found.

The matcher we threw away

The first move was a search anyway, because a search is quick. It looked for the main button of a dialog and found exactly one, in a file with hundreds of dialogs. That is the signature of a pattern that matches almost nothing, and the dangerous thing about such a pattern is that zero is also what a fully guarded codebase would return. We did not report it. We threw it away and asked the page instead.

Asking the page means opening the screen in a real browser, finding the create control by the words on it, pressing it, finding the dialog's primary button, and reading whether it is disabled in the same instant it is pressed. Then pressing it twice in one gesture and counting two things: the requests that reach the wire and the rows that land in the database. Both, because a request that is refused and a request that lands look the same from the browser.

Three screens, three different answers

The suppliers screen had no guard. Two presses sent two requests, and a table that held zero suppliers held two with the same name. The products screen was guarded, and more than that, its button came back after the server refused an empty form. That is the control, and it is the behaviour every screen should have: disabled before the first request leaves, re-enabled on a refusal so the person can correct the form and try again.

The team screen came back as not measured, which is a different answer from passed. Its add button opens no dialog, so the probe had nothing to press and said so. We wrote that down as not measured rather than as a tick, because a probe pointed at a control that does not exist is how a real bug earns a green mark.

Why a duplicate supplier is not cosmetic

A duplicate category is refused by the database, because category names are unique, so a second press shows an error on a save that already worked. A duplicate supplier is not refused by anything. Purchase orders raised over the following weeks land against whichever of the two the buyer happens to pick, spend splits across them, and neither total is the real one. A report on what you spent with a supplier this quarter is then wrong in a way nobody notices until a payment query.

The fix is small and sits in the screen's own idiom. The back office does not load the shared sheet library the guest pages use, so there was no shared busy helper to call. The button is disabled before the first request leaves, which is the line order that matters, and handed back on a refusal. Driven again with the same probe afterwards: one request, one row.

The test that broke was right to break

The new line in the supplier dialog broke two tests about the card reader screen, twelve thousand lines further down the same file. Those tests found their slice of the file by searching for a generic phrase, and the new line became the first match, so the slice ran backwards and both assertions failed against an empty string. It read exactly like the card reader picker having lost its loading state. Nothing about that screen had changed. Both tests now anchor on an id only that screen can have, and we renamed the loading word and watched one of them fail to prove the new anchor still bites.

The walk's own test file holds the three verdicts, and it carries one assertion that looks odd until you think about it: the file must keep saying that everything unwalked is unwalked. Three screens is three screens. The failure this whole exercise exists to avoid is three screens quietly becoming the sentence the back office is audited.