How to Write Test Cases That Catch Real Bugs
Most test suites are thorough about the wrong things. Fifteen variations of an empty field, nothing about what happens when the session expires halfway through checkout.
A test suite can have five hundred cases and still miss the bug that takes down checkout. I have watched it happen. The cases were not wrong, they were just all pointed at the same easy target.
This is how I write them now, from testing booking platforms, where a missed edge case means somebody's holiday is charged twice.
The structure
A case that another person can run without asking you anything needs five parts.
- Preconditions. The state the system must be in. Logged in as what kind of user, with what data already present.
- Steps. Numbered, specific, no interpretation required. "Enter a date" is not a step. "Enter 31/02/2026 in the return date field" is.
- Expected result. What should happen, stated precisely enough to be wrong.
- Actual result. Filled in when run.
- Priority. Which ones run when there is no time to run everything.
The expected result is the part people rush and it is the part that decides whether the case is worth anything. "Error message appears" tells you nothing. "Field-level error appears under the return date, form does not submit, previously entered data is retained" is a real expectation, and it catches the common bug where validation works but wipes the form.
Start from risk, not from the interface
The instinct is to walk the screen and write a case for each field. That produces even coverage across things that do not deserve even attention.
Before writing anything I list what would hurt most if it broke. On a booking platform: money charged incorrectly, a booking confirmed that was never paid, a payment taken for a booking that never confirmed, customer data shown to the wrong account. Those get depth. A misaligned label gets one line.
This is also the reason AI-generated suites feel thorough and are not, something I go into in AI for manual testers. A model does not know what is expensive in your product.
Four categories most suites are missing
State
What happens when the session expires between step three and step four. When the user opens the flow in two tabs and submits both. When they hit back after paying. Almost nobody writes these and they produce a disproportionate share of production incidents.
Timing
The double-click on submit. The request that succeeds on the server after the client already timed out. The webhook that arrives before the record it refers to has been written. These are hard to reproduce and expensive when missed.
Boundaries that are not numbers
Everyone tests the maximum length of a text field. Fewer test the last booking slot of the day, the day a subscription renews, the moment a discount expires, a timezone boundary where the server and the user disagree about what day it is.
The unhappy path all the way to the end
Not just "payment fails and an error shows", but what state the system is in afterwards. Is the inventory released? Is the user's cart intact? Can they retry without starting over? The error message is the easy half.
Write cases that survive the interface changing
A case that says "click the blue Continue button in the top right" breaks when the design changes and the underlying behaviour does not. Describe intent rather than pixels: "proceed to the payment step". You will rewrite far fewer cases after every redesign.
One case, one thing
A case that checks five behaviours fails and tells you nothing about which one broke. Split them. The suite gets longer and the failures get useful, which is the trade you want.
Where the real bugs come from
In my experience, roughly in this order: state transitions nobody mapped, integrations between two systems that each work correctly alone, and assumptions that were true when the feature was written and stopped being true later.
None of those are found by walking the screen and filling in fields. They are found by asking what the system believes, and when it might be wrong.
Related
How AI fits into this work: AI for manual testers. What I do beyond QA: services.
More posts
The tools moved from autocomplete to agents that plan and execute across files. That is a real shift. It also moves the bottleneck somewhere most teams have not staffed.
I pay for more than one of these, which tells you the comparison is not as simple as picking a winner. Where each model is genuinely better, from daily use rather than benchmarks.
Every model is best at something and mediocre at something else. This is which one I open for which task, based on using all of them inside real client work rather than on benchmarks.
AI can write a WordPress plugin in a minute. Whether you should put that plugin on a live site is the part nobody covers. From someone who reviews this code for a living.
Most slow WordPress sites are slow for two or three specific reasons. Here is how to find which ones, in the order that gives you the biggest drop in load time for the least work.
AI can draft your test cases in seconds. Whether those cases find anything is a different question. What a year of using AI tools inside a real QA job actually changed.
AI writes the code in seconds. Someone still has to find out whether it works. A QA engineer’s view of what vibe coding actually costs, and how to use AI tools without shipping their mistakes.
Ten UX/UI trends worth knowing, sorted by whether they change what you actually build or just what design blogs look like this year.
A working checklist for hardening a WordPress site, logins, files, database, hosting and monitoring, written from what actually breaks on sites in production.
AI can lay out a screen, read behaviour data and run usability checks. It cannot decide what the product should be. A practical look at where the line sits.