Rainbow Testing

Finding your way to the Happy Path

{ 03:54, 29 December 2006 } { Posted in Software Testing } { 0 comments } { Link }

Maybe you don’t need to find your way to the Happy Path. Maybe you’re already on the Happy Path. Perhaps when you suggested to your client user group that they define the Happy Path they replied:

Oh yes, that’s outlined in the first Visio diagram on the project SharePoint site. Well, actually, that’s just a link to the actual diagram on our Standards site, maintained by our Standards Manager, Jennifer Wong-Sharma.

…at which moment you found yourself looking into the calm and intelligent eyes of Ms. Wong-Sharma who seemed to understand everything that you needed to get on your way with your test plan for your software development project.
Then you would find yourself on the Happy Path, indeed.
But perhaps your experience has been less optimal.
Perhaps when you mentioned this “Happy Path” you got this:

But all paths are the happy path!

Don’t we have to test everything?

What is a path?

This is perhaps more typical. In this scenario I find myself sitting back and asking myself just why it is that I need a Happy Path and how I communicate this value to my clients.

As allegedly defined by Richard Harrah of HP the Happy Path is:

a default scenario with no exceptional conditions

Because of the lack of exceptions, conflicts, challenges, the path, (or the data flowing over it), is happy.

It is the “default scenario” because it is the thing that the software is being designed to do. If it is a purchasing software, this is a purchasing scenario. If it is a word processing software, this is a document creation scenario. If the software project has a title, or if the end result were put in a package and given a name, this would give you a clue as to the default scenario.

In some cases it is the money path. If this is an application related to your client’s business, then the Happy Path is where the client is making the most money.

In other cases it follows the 80/20 rule – it is the path that handles 80% (or more) of the transactions that flow through this system.

In any case, it provides the project with an organizing principle. Everything exists to serve the primary function – the Happy Path.

What it is not, is a path that shows you other important functions, including error handling, even though these must also be tested. These functions exist to serve the primary function.
When you have this defined, you have the basis for prioritizing your test cases, and, as long as you have the test cases traced back to your functions and workflows, you have a quick list of test cases that provide you with a smoke test, or entrance/exit criteria. If the application can’t walk the Happy Path, it can’t walk at all.

When you define your Happy Path you provide the cornerstone for organizing many of your testing activities, and for a project that needs organization, that’s a happy thing indeed.

« March 2010 »

Mon

Tue

Wed

Thu

Fri

Sat

Sun

Rainbow Testing

Finding your way to the Happy Path

About Me

Links

Categories

Recent Entries

Friends

Syndication