Institutionalizing Poor Quality

Consider the following three scenarios:

• You're shopping at the neighborhood grocery store. As you wander the aisles you come to the meat department. The pastrami looks extra good today. You ask the butcher to slice half a pound for you-extra thick, just the way you like it. The butcher smiles and nods-he knows just what you want. Into the slicing machine the pastrami goes; back and forth the butcher guides the slicer arm; a pile of pastrami forms on the tray below. Just then the butcher steps back from the machine. Suddenly the tester appears. She weighs the pastrami again. She measures the width of each slice. She pronounces the pastrami fit for you, the customer.
• You're at the barbershop. You've just dropped in for a little trim. Yes, you do look a little shaggy around the edges. You explain the kind of haircut you want-just a touch off the front, tapered off just at the top of the ears, squared off in the back. The barber snips and clips, snips and clips, sprays and combs, snips and clips, combs and blows. Then she steps back and he appears-the tester. The tester verifies that the customer's requirements have been met, within the schedule and budget parameters, and with the expected quality attributes.
• 
  With pastrami in the bag and your new haircut, you zoom home without a care in the world. Suddenly, in the rearview mirror, you see flashing red and blue lights. You pull over and wait for the inevitable. Yes, in your hurry you were exceeding the speed limit. "But not by that much," you plead with the officer. The officer takes pity on you (perhaps it's the great-looking haircut) and writes only a warning. Just then, materializing from nowhere, the tester appears. The tester calibrates the speed gun, rechecks your license, examines the warning, declares it acceptable, and makes a prediction about your future behavior.

Why are these stories so silly? The answer is obvious-people in these professions, in the normal execution of their work processes, are simply expected to do a good job.

I was curious about how many fields of endeavor actually have testers. At the local public library I found a four-volume set of books entitled Encyclopedia of Careers and Vocational Guidance. It contained over two thousand pages describing hundreds of occupations. Some of the more interesting (which I somehow missed as I was scavenging around for a career) include animal trainer, bounty hunter, circus performer, dance instructor, edge grinder, fact checker, geomorphologist, horse groom, ironworker, jailer, keno runner, lobbyist, model dresser, nanny, oceanographer, party disc jockey, quilt maker, robot assembler, sponge buffer, tactile interpreter, umpire, vintner, weaver, xylophone repairer, yodeler, and zydeco musician. I only found three careers in this encyclopedia that sounded like testing (which I define as looking for defects in the work products of other people). They are auditor (of various types), aviation safety inspector, and construction inspector. Software testers were not listed. (Perhaps that says something, but that's another column).

What do these three occupations have in common? The auditor checks to make sure no one is breaking rules that would result in huge financial losses. The aviation safety inspector is making sure no one is forgetting something that would result in loss of life as well as loss of money. The construction inspector too is making sure no one is cutting corners that would result in loss of life and loss of money. Hmmm. I see a pattern here. The pattern is that while people are expected to do their jobs properly, in certain professions the risk is so high hat it is imperative that we check again, just to be sure.

Now, let's consider software testers. They check to make sure that the developer's code actually meets its specification. They check to make sure the developers performed their job properly. They may even be making sure that no huge financial losses, or even death, occur as a result of releasing faulty software. Nothing significantly different here. So what is the difference? In many organizations there is virtually no expectation that the developers will have tested their code. There is no expectation that they will have done their job properly!

Why is it even remotely acceptable that people would not be required to do their jobs properly? Why doesn't the organization that institutionalizes the position of software tester then also have painter tester, cook tester, typist tester, shipper tester, nurse tester, receptionist tester, computer operator tester, manager tester, yada, yada, yada tester? Is the creation of software really so different that we don't expect its developers to check their own work?

In her book, The Deming Management Method, Mary Walton explains the philosophies of W. Edwards Deming, the great quality guru.

Deming's basic philosophies are detailed in his "Fourteen Points." Point number three is "Cease dependence on mass inspection." (Note: "Inspection" is Deming's word for all kinds of "testing.")

Explaining Deming, Walton continues, "A company's aim should be to do away with quality by inspection. Even inspection at various stages of production rather than at the very end is no answer." (Does this sound like unit testing, integration testing, system testing, and acceptance testing?) "All too often the pile of defects grows until, in desperation, the parts are used as is." (Sound familiar?) "Quality comes not from testing but from improvement of the creation process."

In our world, the process that needs to be improved is the development process. We should expect developers to build-in quality just as we expect airplane engineers to build-in quality-with testers/inspectors only there to verify quality. It's time to put the first responsibility for a high-quality product back where it belongs-in development, with developers.