THE HAPPY PATH IS EVIL

Hansel and Gretel will back me up on that one…..

In the words of Robert Frost “Two roads diverged in a wood, and I—I took the one less traveled by, And that has made all the difference.”.

Who is the Incompetent Fool that came up with “Happy Path” or “Happy Testing” and why would any testing professional actually use it in a sentence?

I do not allow my staff to use that phrase – ever. I think my reaction to it has frightened them into submission - it’s like Young Frankenstein when someone says “Bluchner”. Horses neigh and dogs howl. My head starts to spin around like the Exorcist and a priest has to be called in. And I’m not Catholic.

When I get an applicant who mentions their years of experience with happy path testing, I have to restrain myself from ripping their resume into little, tiny pieces and flinging it into the air like confetti, swearing in several languages the entire time. The minute the phrase is uttered, I am strategizing as to how quickly I can get them out of my office and back to their colleagues in Hell. It takes a week to fumigate my office – the sulphur fumes tend to linger.

Happy path testing, for those of you blissfully unaware that such a thing could even exist, is taking the most obvious, expected, valid path or paths through a given piece of software to verify the software is Perfectly Lovely and ready to move on to your lucky clients. Companies with no understanding of either software or software quality can embrace this testing policy, since it’s both cheap and unlikely to find much error. Until production, of course. But for some reason, these same companies don’t seem to “count” production errors or time lost by users in prod as part of the project expenditures.

Happy testing is little elves joyfully dancing down the garden path to Mozart, flinging little flowers around as they go.

How unfortunate that our profession is much more in line with a tattooed, leather-clad, chain-bearing gorilla that plows off the path into your garden, rips up all your daffodils and pees on your begonias, followed by blunt observations about the ugliness of your yard, your neighbors, and possibly you and your family as well.

I find it hard to believe anyone would think happy path testing is a Good Idea, but just in case, I’m going to try to change your mind.

Any programmer with even one microscopic drop of competency is going to test their own program(s) by trying the most obvious, expected, valid paths through their software. It stands to reason that the likelihood of driving out error by doing exactly the same thing is slim. Does that mean you DON’T perform those tests? No. There are programmers out there without even one microscopic drop of competency. But it means the really juicy errors lie off the happy path and where paths cross and decisions have to be made.

When you’re either examining an application or a specification, a good tester has to be curious and contrary. The #1 weapon in your arsenal should be the phrase “What if?”. When someone tells you “If A is in X state, and you do B, you will get C result.”, you should be thinking “What if A isn’t in X state? What if A is in Y state? What other states are there? What if I do B without A? What if I don’t do B at all?”, etc. If you’ve never read a spec this way, or looked at a system this way, then just TRY IT. Try it one time and see what happens.

And once you veer into the jungle, you’ll never look back. Believe me, all the fun stuff is off the path….