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.
Quality. The concept is much talked about, especially in a magazine called Better Software . So it seems as if there should be some consensus about what would make software better—what would make it quality. Yet just what quality is, and how we go about achieving it is hotly debated throughout the industry. To help bring the issue into focus for our readers, we reached out to people who are involved in all phases of the software development lifecycle—to people in traditional development roles, and those who are moving to an Agile environment. We spoke to testing consultants James Bach and Bret Pettichord. We talked to vendors: from Microsoft, Harry Robinson; from RadView, Ilan Kinreich; and from Compuware, Dave Kapelanski. Finally, we spoke to people like you and me, those who are out on the front lines every day: people like Beci Karcher and Lisa Skett.
We expected some lively discussions on what quality is and how it is achieved. What we didn’t expect was how much agreement there seems to be among those interviewed. From every perspective, the consensus seems to be that quality software is software that meets users’ needs (though that is much more complex than it sounds).
Give the Users What They Want
For most people we talked to, the bottom line on quality was whether, when a user sat down at his computer, it did what he wanted it to do. As Beci Karcher puts it, "For me, quality is about the end result fitting my needs and the needs of the people I use the software to serve."
Does that mean that refactoring and code reviews should come in second to requirements and design? After all, Dave Kapelanski says, "The end result has to be right for the user, not the developer or the tester."
Lisa Skett seems to agree: "When I sit down at my computer, I only care whether the program does what I want it to do. If not, it doesn’t matter how wonderful the code is."
Let’s not get ahead of ourselves. While requirements and design are important, well-written code can reduce security vulnerabilities, a growing quality concern. Harry Robinson of Microsoft knows well the cost of security bugs. "Software should do what the customer wants it to do. And as we're finding out, it shouldn’t do anything the customer doesn't want it to do," he says.
And if quality is tied to requirements, design, and coding, what is the role of tester? Bret Pettichord sees himself as focusing on the elements of the software that are likely to cause the end user to have a bad experience. "Satisfiers are things that will make your stakeholders happy: the features and capabilities. Dissatisfiers are the shortcomings, design flaws, and bugs that make stakeholders unhappy," he explains. “As a tester, I tend to focus on the dissatisfiers rather than the satisfiers.”
His opinion seems to coincide with that of Ilan Kinreich who says, "If the software doesn't work when they need it, however they need it, no matter what their system or setup—customers won't perceive it as a quality product."
Quality Doesn't Always Last
James Bach made a good point about the fleeting nature of quality, one that many of our interviewees touched on. He gave an example of his old Nokia cell phone. His Nokia was a quality product and did everything he needed it to, and nothing more. Still, it ended up in the trash can when he changed service providers because it wasn't compatible with his new digital network. The world is changing so quickly around a product that
