All year long we've been asking people in every phase of the software development lifecycle to tell us what quality means to them. We found that while most agree on what quality is, there's still controversy over how to achieve it.
The buzz around the software industry is "quality matters." Pick up any technical magazine or newspaper and you'll read about the cost of bugs, the price of poor quality, and the need for improvements throughout the development lifecycle. But do we agree on just what "quality" is?
To get to the heart of the matter, we asked a number of people, "What is quality, anyway?" We chose to question not just industry experts, but also software vendors, the people down in the trenches, and the people running the show. Throughout 2004, we'll explore what it means to "care about quality." To kick things off, let's see what James Bach, renowned exploratory tester and quality guru, and Lisa Skett, a quality assurance analyst, had to say.
Quality Is a Relationship
James Bach believes that Jerry Weinberg has the best definition of quality: value to some person. So who are those "persons," what do they value, and how do you decide whose opinion matters? "Those are questions I find useful to ponder, every day of every project," explains James.
"Quality is not an intrinsic characteristic of software. It's a relationship among the product, the people who have expectations about the product, and the world around them." He gives an example of a Nokia cell phone he once owned. The phone was ideal, reliable, and had good features. "But," says James, "I no longer use it because it's not compatible with my new cell service." The cell phone did everything it was intended to do, but still ended up in the garbage can because the world around it changed. Similarly, if you send a perfectly bug-free product out into the world, and it's more expensive than the customer expected or doesn't do what the user wants, it's probably not going to be perceived as a quality product.
James cautions against trying to satisfy these relationships by conforming to written requirements. "Conforming to written requirements can be a good thing, or it can be irrelevant, but it's never the whole story. The whole story of quality simply can't be recorded on paper. We have to understand what's implied by the written requirements, not just what is explicitly stated. To me, it's more important to stay awake throughout the project and stay in close contact with those who matter."
Often the challenging part is deciding just who matters. James remarks, "It's up to the tester to try to identify all of the people whose opinions matter. A good tester should detect hints of important people not at the table who should be, and pass that information along. In other words, speak up if you think that the final product will be seen as a failure by someone who may be ignorable now, but will be vocal and influential later on."
James also says that testers should focus on providing information. "To think you are the gatekeeper for quality is a self-destructive idea. That way lies madness. Testers don't have the power—or the perspective—to make those kinds of determinations. It's my job to provide the best information I can, both in the ways they want and in the ways I think they should want." He gives an example of a buffer overflow error. Historically, developers may have dismissed it—"Our users won't be entering extraordinarily large numbers into a field. That bug doesn't matter." But that kind of bug can be a boon to hackers. "The hacker sure turns out to matter when CNN is reporting a new virus that exploits the buffer overflow," James adds with a laugh.
"Ultimately, though, your quality goals should be aligned