Is it really an edge case?
Is it really an edge case?
It’s a tale as old as time, as testers we raise a risk or a bug only to be told “that’s an edge case so it won’t be taken into account”. But is that really true, what’s an edge case and should we care?
Dismissing behaviour that could be a real risk with an off hand comment that sounds valid could be an anti pattern that impacts the quality of our systems.
What’s an edge case?
Basically put, an edge case is a behaviour that could happen, but is less likely to happen with our system. Usual this refers to extreme behaviours at the threshold of how things should work (think like boundary analysis where we look at the maximum or minimum of things). Edge cases, as originally defined therefore should refer to things that rarely happen which, understandably, we might not need to consider.
The issue then comes when teams start to say that anything that isn’t the happy path is an edge case. Frequently we can see attempts to raise issues or risks to behaviour (especially when pushing testing earlier) written off as an edge case, something that just wont happen. But is that really the case?
- Is a network connectivity problem really an edge case?
- Is a user putting bad data into the system really an edge case?
- Is a non-200 response really an edge case?
- Is a timeout really an edge case?
These might be unideal behaviours, or negative cases, but they’re not related to thresholds of behaviour. Instead they’re more related to user behaviour that’s just off the happy path… so why might we try to put them aside?
I get it, when team are very delivery focused we can become laser sighted on what’s the minimum needed to get this thing done. Having to widen our scope to include things might take time and effort and thinking that we just don’t have. Or maybe we can start to assume a level of knowledge and familiarity with our product that makes us think that everyone just uses the system perfectly all the time.
But this opens us up to the risk of our system not being error tolerant and not very usable.
What can we do?
Challenge: Ask where’s the data?
If you’re saying that something is an edge case…prove it! Where’s the data that shows how users behave and that this is something that they’d never do? Can we pull out observability findings that show this is an area that we can ignore?
Educate: Show the errors
Explore the implementation and hunt for issues that are off the happy path. We can use this to raise bugs / issues that could have been caught earlier by thinking about non-happy cases up front. We can show how easy it is for users to fall into those failing behaviours, meaning it’s more likely to happen.
Inspire: Build customer empathy
Get product teams to work with support teams or to sit with customers to build an understanding of how they use the system. Share interviews about their pain points or the results of user testing with teams to help them to understand how their product supports them. This empathy, that their product is used by REAL PEOPLE can lead them to want to support them and build better products.
Enforce: Create processes
Work with management to create ways of working around identifying and catering for non-happy case behaviour (Triforce anyone). Or even work to have “edge case” consideration build into people’s performance reviews to make sure they think about them properly.
Creating a shared vision for “what good looks like” that we all buy into means that we can have a shared vision for when a non-happy path is needed.
When working out what to do, we need to have empathy and understand why we’re not looking at certain paths. It may be that our assumed level of quality that’s needed doesn’t meet other team’s members (leading us to the dreaded misalignment and YOUR BAR TO QUALITY IS TOO HIGH). Understanding the team’s vision and creating a shared view of quality will help us challenge on whether something is an edge case or just non-happy path.
Understanding what’s a valid edge case and what’s something that we shouldn’t ignore is an important communication tool when it comes to product development and testing. We shouldn’t be so delivery focused that we start to dismiss anything that’s not on the happy path.
