The question periodically comes up as to what the difference is between “Quality Assurance” and “Testing.” And a disturbingly large number of test professionals will say that “Testing is a subset of quality assurance.” This is a terrible response. Let’s talk about that.
There’s a great article called The Illusion of Quality Assurance and I’m not going to repeat any of it here. Rather I believe that part of the reason there is an illusion is because many professionals don’t unpack suitcase words like Quality Assurance and Testing. And when they do unpack those words, they do so with eye towards “subsets” like the response I just mentioned.
So let’s just consider that we can use one of the standard definitions of quality assurance: “the maintenance of a desired level of quality in a service or product, especially by means of attention to every stage of the process of delivery or production.”
By that logic, everything is a subset of quality assurance: development, business analysis, etc. This, I believe, is true. Treating this as if it were true, however, requires you to realize that quality assurance cannot be just a team. Quality assurance is a distributed function across teams. And when I say “function” treat that as an ongoing human process that leverages individual areas of knowledge to determine what quality looks like for a product or service, particularly when accounting for the experiences that you believe most add value to customers engaging with the product or service.
Another thought follows from this: which is the idea that everyone tests but not everyone is a (specialist) tester. Testing is not just an execution activity, it is also a design activity. Testing, as such, puts pressure on design at various levels of abstraction. When doing so it is possible to utilize various tools and techniques that support that testing. All of that is informing the broader notion of “quality assurance” — even though none of it, by itself, is strictly speaking, assuring quality.
But we can even unpack this further.
Testing is not just an execution activity and it’s not just a design activity: it’s a framing activity. Testing provides a narrative around a model — a heuristic fiction, if you will — that allows teams to understand the current state by also having access to the historical state. What testing does is situate sequences of events along the skein of time. That’s history informing the present and the future. Let’s even go one step further. What we call “culture” is precisely the organization of the current situation in terms of a particular past. As such testing is a very cultural activity and a social discipline.
What all of this “testing” is doing is exposing intransparency and thus risk. Not just in our product or service. And not even just in our processes. But also in the culture in which all of that is situated. Testing is helping all of us better expose the sensitivities and problems inherent in our products or services. Sometimes these are bugs, sometimes these are flawed models, sometimes these are issues with how we all communicate.
Quality Assurance and Testing are suitcase words. We fundamentally misunderstand the function of quality assurance and the discipline of specialized testing when we don’t unpack those suitcases.
