Quality Products and Product Quality
I changed my tagline today, and I wanted to write down what I meant before I forget. 🙂
The motivating factor behind every purchase is a need that a person seeks to fulfill. It stands to reason, then, that a product that fails to meet the need it claims to fill is not a quality product. Whether that’s because it’s designed poorly and doesn’t accomplish much of anything, or because it is designed well but meets a different need, if it fails to meet the need the buyer purchased it to fill, it is not a quality product to that buyer. Across the chasm, once we find a product that meets a need, if it suffers from reliability issues and just flat-out doesn’t work well, it suffers from poor product quality.
In the lexicon of software quality assurance, these concepts are described in terms of verification and validation–verification answers the question “are we building the right system?” and validation answers the question “are we building the system right?” This demands that an organization push quality assurance up from the end of the SDLC towards the beginning, so that QA Engineers are involved with the initial design and specifications. Additional eyes on design artifacts at early stages of development help to expose potential problems and guarantee more of the right questions are asked early enough for them to make a difference, rather than afterward when the only question that can be asked is “I wonder what would have happened had we….?”