In the context of software or information modeling, a happy path is a default scenario featuring no exceptional or error conditions, and comprises the sequence of activities executed if everything goes as expected
- Wikipedia
Software is possible because we have clear, well-defined expectations in a lot of common situations. Given a problem and a particular state of the world, software can reason through known information, and perform according to the expectations.
People who invent software are enterprising, excitable, focused on delivering a working solution for a problem. Which mostly translates into building software that is great about performing the ‘can do’ portion of the expectations. It is the so-called happy path, where the software works as desired and designed, in the perfect world for the well-behaved user who happens to think in perfect lock-step with the inventor of the software.
However, the world is hardly ever perfect. People and users think differently. Not all users are both well-behaved, and can or will follow the detailed vision of the software designer.
Consider a bank application that allows read access to one’s account balance. It is important that it does NOT
- allow read access to other people’s account balance.
- allow write access to any account balance.
- allow any user behavior to affect other user’s experience and access.
These kinds of expectations are less likely to be included in the specification, because we like to think about software in terms of what it can do, and not what it doesn’t do. These expectations are less likely to be designed into the software architecture, because we like to think of achieving our goals must more, than we like to be concerned about preventing bad things from happening. Finally, these expectations are less likely to be tested, because it is both harder and does not demonstrate a job-well-done even if successful.
Better handling the non-happy paths requires a more systematic approach to specification building and testing, and range verification.