Five Frontend Bugs Developers Should Catch Before QA
A short checklist of bugs that are cheap to fix in code and expensive to find in QA.
The cheapest bug is the one a developer catches before a pull request reaches QA. These five checks take minutes, but they cover the states that polished screenshots and happy-path demos usually miss.
Empty and zero-result states
If a list, search, dashboard, or form can be empty, design that state before filling it with sample data. Explain what happened and give the user a useful next action. A blank panel is not an empty state; it is an unanswered question.
Loading states that tell the truth
A spinner that disappears before the content is ready creates a flash of nothing. Keep loading feedback tied to the real request, preserve the page layout, and make retry behavior clear when the request fails.
Keyboard focus and visual order
Tab through the feature from the address bar to the final action. Focus should move in the same order the interface is read, every interactive element should have a visible focus style, and opening a dialog or menu should never lose the user.
Dates across locations
Dates that look correct on one machine can move a day when rendered in another timezone. Test a real timestamp in at least two regions, decide whether the product means local time or a fixed moment, and format it consistently on the server and client.
Form errors that stay visible
Place an error beside the field that needs attention, summarize multiple errors when necessary, and move focus deliberately after submission. If the message appears outside the viewport, the form feels broken even when validation is technically correct.
QA should explore deeper risks, not repeatedly rediscover missing interface states. A short developer pass with real data, keyboard navigation, a slow connection, and a second timezone gives the team a much stronger starting point.