It is with some apprehension that I launch myself upon a discussion of product quality and QA testing. While product quality is promoted by Marketing and management, people rarely want to see and touch the distasteful details of the QA testing that helps improve software quality.

I suppose an outstanding quality effort flows like a stream, steadily and smoothly, out to an ocean of customers. Then there’s the situation for the rest of us.

Much of the struggle with QA testing in the software industry probably stems from the mistaken belief that, in an ideal situation, testing would hardly be necessary. That by finding the right magic formula of programming, such as the double-helix cross-pollinated self-actualized awesome programming method, there would be virtually no bugs in the code and no need for testing. This belief is a distortion of the quality dictum that better work upstream results in fewer defects downstream.

I know there are software development organizations that achieve truly impressive levels of defect-free output. Hats off to them. I, on the other hand, have found it helpful to understand some of the difficulty that occurs naturally in the effort to improve product quality. Some quality events (some would call them “problems”) happen very naturally.

I compare the creation of software, and QA testing of it, to a stream or river. It’s a long stream of code that starts at the source and flows through turns, falls, and rapids to the customer base. And the QA issues we all face are like some of the situations normally encountered along a river.

Read on below for a discussion of QA testing and the river of product development where it takes place.

[private]

Toe In the Water

One of the decisions an organization is continuously challenged to make is to answer the question: “Just how much QA do we want to do?” While plunging into the stream and swimming valiantly for the other shore gets you fully engaged in testing, putting a toe in the water is a valid option.

In a world of limited resources, each company faces tough choices between allocating enough resources to QA testing (and quality in general) and cutting into its resources for development. It can truly be a difficult choice. There are many outfits out there that fully realize that by not having more testers they will have more defects down the road. But they choose to live with the pain.

Swimming Upstream

Wouldn’t it be great if QA testing were easy? If testers were greeted enthusiastically when they found bugs and brought them to a developer’s attention? If only top management woke up every morning with the thought that “QA testers are our most valuable resource.”

In reality, doing quality assurance on the stream of new product development is like swimming upstream. It takes a certain amount of perseverance on the part of QA testers just to be heard and understood, let alone listened to. Testers need to possess a bulldoggedness in order to chase down problems and push for their resolution.

The effort to do QA testing is a lot like the energy-intensive voyage of salmon upstream to the headwaters. And expecting it to be anything else, expecting to be able to coast along, just means your testing effort will get swept out to sea.

The (Purest?) Source

Working on quality at the very beginning of code development is like going to the wellspring, the very source of the river. There’s a tremendous energy as ideas are bubbling to the surface, and things look so clean and simple. There’s no getting around the fact that if you can get QA testers involved in review of the product design from the get-go that you can prevent certain problems from even occurring.

But that placid spring water may not be all that clean. It just looks wonderful while it’s standing still, before it starts its inevitable descent down the product development path.

Waterfalls

Once code begins to make its way towards the customer, QA testers may be in for some pretty stomach-churning descents. The first rush of code coming out of Development can be rough. It pays to expect things that crash and drop right before your eyes.

But this is all part of the process of taming and channeling the output that is heading over the cliff from Development. This is a good point to bolster your QA effort by getting developers themselves involved in spot-checking and unit testing each other’s work.

When you rely on other developers to test the work, the rest of the organization is spared some of the more dizzying falls.

Whitewater Rapids

In addition to the waterfalls, there are the inevitable rough waters. Integrating separately developed capabilities and testing to see how they all work together is bound to make for a bumpy ride.

Your QA effort can benefit at this point from understanding, and helping the rest of the organization understand, that rocky waters are a natural part of the process of testing and improving a product. If you’re exceedingly lucky, you hit only one or two rough patches. But usually there are several of them, and just because you’ve hit another rough patch doesn’t mean that things are going nowhere. Another turn of the river and things will flow more smoothly.

Stagnant Pools

As the product development stream begins to move more evenly and to slow down, you will struggle with the fact that while the main current, the heart of the product, may get lots of attention, other defects and problems will get relegated to the backwaters. QA testers can be very helpful at this point by making sure they continue to churn through all areas of the product, making sure that forgotten bugs are resurfaced and followed up on.

Sewage Treatment

Sometimes, as product development gets close to release to customers, things reach crisis proportions in specific areas. QA needs to kick up a fuss over the problem and make sure that serious remedial action is taken. It can seem like a thankless task to get the sludge cleared out, but will be vital to the success of the product.

There’s no harm reminding management of the valiant efforts that were made, both on the part of QA and Development, to tackle some of the messier cleanup jobs.

Polished Stones

You’ve probably seen those smooth, rounded, polished stones that can be found in certain places along the banks of a river. They’re the product of gritty water washing over them and wearing them away until no rough edges are left. They’re a symbol of both the power of your product flow to change the hard and fast limitations it bumps up against, and your inability to completely remove them or wash them away.

Every product winds up with its share of polished stones. QA and Development usually know the ugly stories that lie behind some of those quirks of the interface and functionality. They know just how rough those obstacles were before they got worn smooth. Worn smooth, but not worn away.

For example, your product may be set up to display the following columns every time it lists an individual: Name, Work Phone, Cell Phone, Office Building. These fields appear every time a person is listed anywhere in the software. That works great in the My Coworkers list. But it looks a little strange when you use it in the Vendor Contacts dropdown. What you really need there is the name of the vendor, and no office building. But the effort to make this configurable in all the various instances where people are listed is just too extensive to tackle, at least for the upcoming release.

QA can help provide some of the background story to the customer-facing portions of the organization, so that everyone understands that Development did the best it could with limited resources. And more importantly, everyone understands that a lot of deliberate thought and well considered tradeoffs were involved.

Delta Silt

Finally, there’s the equivalent of the delta silt, the imperfections that settle out after your product has been released into the ocean of your customers. Certain defects and impurities will simply make it all the way through testing and remain in the product. As new development keeps flowing out, a whole area builds up where customers carve out channels and workarounds and learn to live with them.

QA testers can help identify those areas that build up into major problems, requiring the equivalent of dredging the channel to make it passable again.

It’s Only Natural

While the passage of your product development, from the headwaters out to the ocean, may not exactly be smooth sailing, much of it is only natural. QA can help the rest of the organization ride out the drops, bumps, and turns to a successful product.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]