Edge Cases: Finding the Ones Worth Writing Down

An SDET on a payments team sits down to list edge cases for a new refund feature and stops after twenty minutes with sixty items on the page. A currency with three decimal places. A refund larger than the original charge. A refund issued the same second the original charge posts. The list could keep going indefinitely, and that is exactly the problem: edge cases are infinite, and the real skill is not finding more of them, it is deciding which ones deserve a permanent test case.

This post is about that decision. It covers what an edge case actually is, how it differs from a boundary and a corner case, where these cases come from in real teams, and a concrete way to decide which ones are worth writing down.

What counts as an edge case, a boundary, and a corner case

These three terms get used interchangeably, but they describe different things, and the difference matters for how you find each one.

• An edge case is an unusual but valid input or condition, one that sits at the extreme end of what the system is expected to handle. A refund for exactly the amount of the original charge, filed the same millisecond it clears, is an edge case.
• A boundary is the specific value at the transition point of a valid range, like the exact minimum or maximum a field accepts. If a discount field accepts 0 to 100 percent, the boundary values are 0 and 100 themselves, plus one step on either side.
• A corner case is what happens when multiple edge conditions occur at the same time. A refund at the maximum allowed amount, in a currency with three decimal places, submitted during a scheduled maintenance window, is a corner case: three edge conditions stacked together.

Boundary value analysis is a structured technique for finding boundaries specifically. Edge cases are the broader category boundaries belong to, and corner cases are the rare compound version of an edge case.

The selection criterion: what stops the list growing forever

Given enough time, anyone can generate an unlimited list of edge cases. A refund on a leap day. A refund in a currency that just changed its decimal precision. A refund submitted from a browser tab left open for six hours. None of these are wrong to think of, but writing a permanent test case for every single one is not realistic, and it is not useful either.

The selection criterion that actually works is cost of failure multiplied by plausibility of trigger. An edge case earns a permanent test case when it would be expensive if it broke, and when the condition that triggers it is plausible enough to actually occur in production, not just theoretically possible.

A refund exactly matching the original charge amount is both expensive to get wrong, since a mismatch means real money moving incorrectly, and highly plausible, since it happens constantly in normal use. That earns a case. A refund filed during a leap day is unlikely to cause real financial harm even if it did briefly misbehave, and it happens once every four years. That one probably does not earn a permanent case, even though it is a genuine edge case.

Where edge cases actually come from

Teams that are good at finding worthwhile edge cases are not smarter, they are pulling from better sources. Three sources produce most of the edge cases actually worth documenting.

• Production incidents. The Safari only checkout bug that reached a customer, or the refund that silently failed for a specific currency, are edge cases the system already proved it could hit. These deserve a permanent case almost automatically, because they have already shown their cost.
• Exploratory testing sessions. A tester poking at a feature without a script often stumbles onto a condition nobody thought to write down, like submitting a form twice in quick succession before the first response returns.
• The boundaries of the data model itself. Every field with a minimum, a maximum, a required format, or an enumerated set of allowed values has boundaries built into its definition, and those boundaries are a reliable, almost mechanical source of edge cases worth checking.

Production incidents are the strongest source because they come with proof of cost attached. A near miss that a tester happens to find during exploratory testing needs the cost times plausibility test applied before it earns a permanent spot, but an incident that already reached a customer has already answered the cost question.

A short exercise for a real backlog

Pull up any feature with a numeric input, a date field, or a currency amount, and try this exercise. List every edge case that comes to mind in five minutes without filtering. Then go back through the list and score each one on a simple scale: cost of failure as low, medium, or high, and plausibility as rare, occasional, or common.

Anything scoring high cost and common plausibility gets a permanent case immediately. Anything scoring low cost and rare plausibility gets dropped without guilt. The cases in between, medium cost with occasional plausibility, are where judgment actually matters, and that is usually a small enough group to discuss with the rest of the team in a few minutes.

This exercise works because it turns an open ended brainstorm into a short, defensible list. A reviewer questioning why a case exists can point to the score instead of relitigating the whole conversation from scratch.

Five edge cases for a payments example, and why each earned a case

Take a refund feature on a payments platform. Here are five edge cases from that feature, each with the reason it made the cut.

1. A refund for the exact amount of the original charge, filed within one second of the charge clearing. High plausibility, and a failure here means money moves incorrectly. Earned a case.
2. A refund amount specified in a currency with three decimal places, like Kuwaiti dinar. Plausible for any platform with international customers, and a rounding error here directly costs money. Earned a case.
3. A refund larger than the original charge amount. This should never be allowed to succeed, and if the system fails to block it, the cost is a real financial loss. Earned a case.
4. A refund submitted twice in quick succession by a customer double clicking the button. Highly plausible given ordinary user behavior, and a double refund is a direct cost. Earned a case.
5. A refund filed for a transaction that already had one partial refund on it. Common enough in customer support workflows, and getting the remaining balance wrong is a support ticket waiting to happen. Earned a case.

Notice what did not make the list: refunds during a specific astronomical event, refunds from a browser with JavaScript disabled, refunds where the customer's name contains an emoji. All are technically edge cases. None of them cleared the bar on cost, plausibility, or both.

The SDET with sixty items on the page does not need to find more edge cases. She needs to run each one through the same two questions: how expensive is this if it breaks, and how likely is it to actually happen. That is what turns an infinite list into a suite someone can actually maintain.