In software development, an edge case is a type of software bug that won't be a widespread issue. Instead, it only affects a small number of users, and devices, or can only be reproduced under uncommon circumstances.
That doesn't necessarily mean that the bug is difficult to reproduce. An edge case in programming can be just as easy or difficult to reproduce like any other bug.
It's the uncommonness of edge cases that gives them their name. Because they affect a small number of users, they might be seen as superfluous, important yet difficult to treat, and generally challenging to understand. Product teams should still work to overcome edge cases, though the process of doing so may be a bit different from how a typical bug is approached.
When working within a product team, you may want to change how you think about edge cases. While it's generally not a good idea to prioritize an edge case over a standard bug that affects all of your users, that's not enough of a reason to ignore edge cases altogether.
Edge cases are likely to be discovered by users at some point, and they can be exploited by hackers, who make a habit of discovering edge cases.
When discussing an edge case in programming, you may hear corner cases brought up in the same conversation. Corner cases are a type of edge case, but are a bit more complex.
An edge case occurs when a user finds themselves operating software under a unique condition that leads to a bug. A corner case is when multiple unique conditions are at play.
For instance, finding a bug that only occurs on iPhones is an edge case. But a bug that only occurs on iPhones when music is playing and the user has cleared their notifications, that's a corner case.
Differentiating an edge case from a corner case is as simple as looking at the number of factors at play. If a bug only appears whenever multiple limiting factors are at work, then it's a corner case, not an edge case.
To uncover corner cases, you want to push your code to fail. Consider each line that a feature uses to execute and consider all of the ways that it might backfire. Test these in different combinations, use print statements to expand your dataset, and most importantly, write readable code.