How to Write Test Cases That Catch Real Bugs

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.

Другие записи