In general, developers test features by focusing on the positive outcomes — the so-called “happy paths”. Unfortunately, this optimism can blind us to the less obvious or less probable outcomes that can cripple an application. I found one way to counteract this tendency is to try and “go beyond the happy path” by exploring the outcome of unhappy paths through a feature. I came across this idea in the excellent book Fifty Quick Ideas to Improve Your Tests by Gojko Adzic, David Evans, and Tom Roden, and expanded upon the book Writing Great Specifications by Kamil Nicieja.
When writing your tests, you can go through the following list of paths to generate test scenarios you maybe hadn’t thought of.
The Happy Path
The main success scenario, usually the most straightforward example. In the happy path, everything goes right.
The Angry Path
The main failure scenario. Look for anything that will make the application throw errors, quit, or break. A counterexample to the happy path.
The Scary Path
The highest area of risk. Things that could get you or the user of the application fired or demoted. Catastrophic errors.
The Embarrassing Path
If something broke, what’s the most embarrassing thing that could happen. Imagine given a demonstration of the feature to stakeholders — what is the most embarrassing failure that could happen during your demo.
The Delinquent Path
If a malicious actor was given access to this new functionality, what is the worst they could do with it?
The Stressful Path
What example scenario could stress your system to its limits? How much data is too much data to handle? Can you handle projected business volume?
The Greedy Path
What happens if you order lots of everything? Opt-in to every last option? Imagine being the most extreme power user you can imagine.
The Desolate Path
Does the new feature function for new users? What happens if someone can’t fill in a field. Go through the feature giving too little information and filling out as few forms as possible. Does the function still work?
The Forgetful Path
Be purposefully forgetful. Fill a shopping cart full of items and don’t check out. Never check of approvals assigned to you.
The Indecisive Path
Constantly change your mind. Edit what you’ve written. Change photos you’ve uploaded. Reposition items on your screen.
Exploring Outcomes
By acting through each of these paths, you will be exploring the functionality of your application and figuring out what outcomes to expect from what type of behaviour. Do these outcomes still solve the business need and fulfil the functionality you are trying to develop? Answering these questions will lead you to more robust and better quality software.