In response to yesterday’s post on The Happy Path colleague and friend Albert Gareev raises an important issue:
Until we sufficiently learned about the users, the product, and the environment, we have no idea what usage pattern is a “happy path” and what would be the “edge cases”.
I agree with Albert. (See more of what he has to say here.) This points to a kind of paradox in testing and development: some say that we can’t test the product unless we know what the requirements are—yet we don’t know what many of the requirements are until we’ve tested! Testing helps to reduce ambiguity, uncertainty, and confusion about the product and about its requirements—and yet we don’t know how to test until we’ve tried to test!
Here’s how I might address Albert’s point:
To test a whole product or system means more than demonstrating that it can work, based on the most common or optimistic patterns of its use. We might start testing the whole system there, but if we wanted to develop a comprehensive understanding of it, we wouldn’t stop at that.
On the other hand, the whole system consists of lots of sub-systems, elements, components, and interactions with other things. Each of those can be seen as a system in itself, and studying those systems contributes to our understanding of the larger system.
We build systems, and we build ideas on how to test them. At each step, considering only the most capable, attentive, well-trained users; preparing only the most common or favourable environments; imagining only the most optimistic scenarios; performing only happy-path testing on each part of the product as we build it; all of these present the risk of misunderstanding not only the product but also the happy paths and edge cases for the greater system. If we want to do excellent testing, all of these things—and our understanding of them—must not only be demonstrated, but must be tested as well. This means we must do more than creating a bunch of high-level, automated, confirmatory checks at the beginning of the sprint, and then declaring victory when they all “pass”.
Quality above depends on quality below; excellent testing above depends on excellent testing below. It’s testing all the way down—and all the way up, too.
Hi Michael,
What if we apply heuristics to find what the happy path of testing might be?
Michael replies: Well, sure. Everything we do in testing is heuristically based. It seems like what you’ve done here is to use a set of guidewords that we use for recognizing problems, and you’ve adapted those guidewords to the task of learning about the product. That’s cool.
For example if we had to use the FEW HICCUPS heuristic approach to finding the happy path we could approach it as follows:
Familiarity – we try to design the happy path according to similar products that may have been tested by us before.
Explainability – we should be able to explain the happy path thoroughly to anyone that may ask us on it.
World – we can try base the happy path on what we observe or experience in the living world.
History – we approach what the happy path may be according to testing previous versions of the software.
Image – or perhaps in this case perhaps replace image with imagination. Approach the happy path according to how we imagine the intended customer may take.
Comparable Products – if there is a comparable product, there should be a help guide right? What if we apply this help guide to help us find the happy path to the program.
Claims – if we work off what the product owners claim it should do, then that should also help in testing the happy path right?
Users’ Desires – what if we consult with intended users and find out what their expected happy path would be.
Purpose – surely the happy path will be based on the purpose of the product.
Statutes – if the system needs to follow a strict set of rules then the happy path should follow these restrictions and laws.
Ultimately I know that this approach is fallible but it could give us a great framework to start testing the happy path or at least help us understand where it may lay.
Keep up the great work.
You too!
[…] Finding the Happy Path Written by: Michael Bolton […]