What does Quality mean in Software Development? As it's used today, Mike Bria notes: ‘Quality’ refers to the "lack of defects" instead of "presence of value", as it means in more common everyday use.
He goes on to suggest:
"Quality" should be used as a measure of functional/aesthetic utility to our consumer, and not as a measure of defects. Really, it should just be assumed that defects are generally absent. This should just be implied in what it means to be a Professional.
So: I hereby propose we as software professionals and businessmen stop using the word "quality" to mean a "measure of defects".
Mike thinks that we get people writing less fragile code if the focus is not on quality seen as less defects, but quality as fit for use by the consumer. He can think of no other product where the user would say it is good quality where all that meant is that it has few defects. Yet that is exactly what we settle for in software.
Lisa Crispin, co-author of Agile Testing: A Practical Guide for Testers and Agile Teams, commented “I have never liked measuring defects so it's hard to think about what to call it.”
Christian Vest Hansen, quoting Robert Glass, says that quality is:
…a collection of attributes: portability, reliability, efficiency, usability, testability, understandability and modifiability.
Each of these attributes may rank differently in importance for different projects, but quality can never be any one of them alone. Some projects may not care about portability at all, and a product that is only reliable and nothing else, cannot be considered a quality product.
James Bach thinks that the traditional view of quality is a myth that’s not inline with software development: “The quality of a product is built into it by its development team. They create quality by following disciplined engineering practices to engineer the source code so that it will fulfill the requirements of the user.” Instead he proposes a new myth:
A product is a dynamic arrangement, like a garden that is subject to the elements. A high quality product takes skillful tending and weeding over time. Just like real gardeners, we are not all powerful or all knowing as we grow our crop. We review the conditions and the status of our product as we go. We try to anticipate problems, and we react to solve the problems that occur. We try to understand what our art can and cannot do, and we manage the expectations of our customers accordingly. We know that our product is always subject to decay, and that the tastes of our customers vary. We also know that even the most perfect crop can be spoiled later by a bad chef. Quality, to a significant degree, is out of our hands.
After many years of seeing things work and fail (or work and THEN fail), I think of quality as ephemeral. It may be good enough, at times. It may be better than good enough. But it fades; it always fades, like something natural.
Finally, JB Rainsberger suggests: “When we stop chasing objectively measurable quality, we come back to trying to satisfy specific people, I posit that helps us deliver more appropriate, more profitable software.”
It would appear that there is no clear agreement on what quality means. Instead there is agreement that quality isn’t a measure of defects. The authors agree that we need to call a spade a spade, so we should acknowledge defects as deficiencies.
