The Effective CIO

The Happy Path November 2, 2009

In our last episode, I argued for a more consistent application of the 80/20 rule as we design and deploy software.  I made an exception for testing, however, which prompted a comment asking why testing gets exempted from this rule.

As the saying goes, testing only proves the presence of bugs, not their absence. The goal of testing is to find as many of these bugs as possible before moving code into production, in the hope that we will avoid inflicting them on our poor unsuspecting users.  Unlike a system in which we intentionally design and deploy the first eighty percent so as to get some value to the customers more quickly, we cannot test just eighty percent using a similar rationale. We need to test everything we build as best we can.

There is a limit, of course.  You can’t test forever.  The trick is to know what to test, and to test those parts thoroughly.

A co-worker of mine often talks about the “happy path.”  The happy path is the path through a system where everything works, the data is correct, the system stays up, and the users are well-behaved.  We tend to test the happy path first because we understand how the system should function and want to ensure that the basic features should work.

This results in testing scenarios like this

• User selects an item and adds it to their cart
• User enters billing data
• User enters shipping data
• User clicks “Check Out”
• Transaction is processed

If this works, has the system been tested?  Yes.  Would you move it into production? The right answer is “no,” but I’ve used a lot of systems where the apparent answer was “you bet!”

We need to move off the happy path and wander in the weeds.  What if the quantity exceeds stock on hand? What if the user enters too few digits from their credit card? Or too many? Or adds a space, or a dash? What if the zip code doesn’t match the state? What if? What if? What if?

It doesn’t take long to test the happy path.  It takes forever to test everything off the happy path. You need to spend a lot of time wandering away from the happy path, and maybe there is a reverse rule for testing: 20% of your time on the happy path; 80% of your time off of it.

For some reason, I was born off the happy path.  Even at a young age, I was doing things like sticking Christmas lights directly into outlets (they explode and leave a mark on the wall) and riding my bike with my eyes shut (you hit parked trucks and knock yourself unconscious).

I have developed a reputation as the guy who can break things, much to the chagrin of every development team I have ever worked with. I wish I had a nickel for every time I’ve been told “no one ever tried that before.”  As much as it annoys developers, people who can break things are crucial to building solid products.  Better that we break them instead of a user.

We need to find and engage the non-happy-path people in our teams, and make sure that they spend a lot of time testing everything we build.  Admittedly, you cannot test forever, but having the right people test for as long as possible can make a world of difference.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio125″ only_single=false]