I’ve been running QA teams for about a decade, now. And in that time the QA industry, like many others, has changed dramatically. But the need to deliver quality is increasingly important. Fundamental to incorporating quality is understanding what quality really means. What are the attributes of quality, and how does one apply it to products and work processes?
To bring water to a simmer, you set the heat on the stove and wait. Set it too high and the second you turn your back it boils over. Too low and you’re wasting time. This struggle is a result of a lag in feedback. If the water were to bubble up or down at nearly the same rate as you turned the stove’s knob it would be simple to set a perfect simmer every time. There are two elements at play: 1) the speed of the feedback and 2) the desired outcome.
When developers make code changes, historically, they have had to wait for feedback. Waiting for a build server, configuring a test environment, generating or finding test data, and waiting for quality assurance to test a staggering variety of operating systems, browsers, and countless devices, the change could result in waiting days or weeks, and due to differences between the test and production environments, the results would be only so reliable. If you haven’t got your CICD pipelines in ship shape, you may still be doing this. This is a barrier to the first element of our simmering water experiment: speed of feedback.
Another problem comes from expectations. Without clear requirements from the business, the developers and testers are often obliged to rely on their intuition for determining what constitutes “quality.” This is a barrier to the second element: the desired outcome.
Quality isn’t a verb. You don’t “do quality.” It’s an attribute which, put simply, means that a thing has met some standard
In order to have a clear picture of our desired outcome we are obliged to revisit what quality actually means. And that takes some deliberate thought. Like discerning art from pornography, we typically believe we know quality when we see it. But chances are you’d be hard pressed to offer a concise definition of quality if you were put on the spot. Can you concisely define quality right now?
“Quality is not an act, it is a habit,” a quote often misattributed to Aristotle, but the point is made: Quality isn’t a verb. You don’t “do quality.” It’s an attribute which, put simply, means that a thing has met some standard. No standard, no quality. Undefined standards necessarily means undefined quality.
When you make a product (or process!) without clear standards, then your standards default to the instincts of employees who may not be clear (or even agree) on the expectations of your business partners. They might not be consciously aware of how they make pass/fail decisions. Your standards would be largely subjective, making the outcome’s level of quality undefined.
In order to automate quality, you first have to tell the computer what quality means to you, and it has to be in terms clear enough for a computer. We can no longer get away with being a little fuzzy about the specifics. The computer can’t determine your definition of quality. It can only follow your lead. Only once you have established clear standards can you automate their enforcement.
A quality engineer can do more for you than just write automated tests. He or she can help identify quality measures, and automate the detection and enforcement of those measures – standards – so that developers can get accurate information about what is wrong quickly. The speed of the feedback is most valuable when the feedback is clear.
If you want quality, you have to have standards. And if you want quality quickly, you have to validate meeting the standards and deliver the feedback quickly. I recently heard a common axiom turned on its head. Don’t think of it as “fail fast.” The trick really is to “validate fast.”