Who is “responsible” for quality? This is one of those interesting questions that on the surface of it seems really simple to answer depending upon your viewpoint … and yet the question itself hides a few thorny issues. In my experience, most people who claim they are part of a “Quality Assurance Team” are not aware of these issues and thus perpetuate a lot of false thinking regarding the question itself.

It’s very important to think about what this question actually implies. How this question is considered directly ties in with how we think about the notion of responsibility and about how we communicate that notion to others.

What I usually hear from people is that the QA team “assures quality.” At first glance that certainly seems to make a lot of sense since the team is called Quality Assurance. However, there are some Quality Assurance practitioners who will argue that a QA team does not assure quality, but rather will attempt to ascertain it. The implicit idea with that slight rewording is that a QA team can’t strictly improve the quality of a product; they can only prove there are bugs. Assuming this, such people say that a QA team most certainly can’t do something as grand as “assure” the presence of quality. As you can probably imagine, the stance people take tends to be quite reflective of how their teams operate in their organization and the level of responsibility they are often given.

Where do I fall in the debate? Well, for right now, let’s just say I won’t advocate any position wherein it’s possible for management to feel that just because there is a team called “Quality Assurance” the organization can expect a quality product. Sorry, but it doesn’t work that way. I say that because what’s often missing in all of this is simply this question:

What’s the definition of “quality” being used?

After all, if I’m told I’m going to be responsible for something I want to make darn sure I understand what that something is. Assuming you don’t just equate quality with lack of bugs, then you have to realize that quality is situational and contextual. I don’t like to frame it as a semantic debate as to whether I do or do not “assure” quality. I personally think that worrying about whether I “ensure”, “assure”, and/or “ascertain” is simply a way of skirting the issue. If we really want to go all dictionary on this thing, the words “assure”, “ensure”, and “insure” all basically mean “to make certain (of something)”. English tends to use the phrase “assure” in terms of personal statements (“I assured him that the product had zero showstopper bugs.”) Yet people tend to use these words pretty much on an equal footing, although I do like to point out that in correct usage only “insure” is used in the strictly commercialized sense of “a guarantee to persons or property against a stated risk.” But we really don’t speak of quality insurance, do we?

Let’s reframe the context… What if we look at how quality assurance, as a function rather than as a team, influences quality.

In fact, I think that’s a much better way to frame the question. Asking how something can be influenced, however, presupposes knowledge of what that something is. If you have such knowledge, then that means you have a goal-directed statement of what “quality” means. Further it means you have the basis for laying out certain spheres of influence and responsibility based on certain aspects of quality.

What this allows you to ask is this: within certain spheres of influence, who is directly responsible for certain aspects of quality? This is a fundamentally different approach than asking, at a general level, about the “gatekeepers of quality” or about who actually handles quality in the organization or, dare I say it, who is “responsible for quality.”

So does that bit of contextualizing help? Instead of saying:

“There are specific people who handle quality and are gatekeepers.”

we can say

“There are various people who handle (certain aspects of) quality and those people are gatekeepers (for their area of quality).”

I can easily see someone saying that it sounds terribly simplistic when I say it like that. Alternatively, perhaps it sounds like I’m splitting some very fine semantic hairs. However, the reason I like to think of things this way is because I find it helps me avoid the trap of thinking that quality is an “either-or” element. (Don’t fall into the tyranny of the or!) It’s not a case that you either have quality or you don’t. Quality comes along at many points in the process. Not all people are involved to the same degree in each area of the process. Quality has a context.

Okay, so how do we find that context? Maybe we can use testing to find that context. Is that possible? Well, let’s consider something of a specific example. Consider an environment where one of two possibilities hold true:

• The QA team is held responsible for the final quality of the product. When a bug is found in production, the common refrain is “How did this get out of QA?”
• The QA function is held responsible for the final quality of the product. When a bug is found in production, the common refrain is “What’s the earliest time we could have caught this?”

In the first case, quality assurance is a team (and is in fact usually just a test team with a fancier title). The implied idea is that the product life cycle is like a funnel that leads down to the testing function, which should find any and all problems. The opportunities to find the problems focus mostly on testing and usually testing done against a working version of the product.

In the second case, quality assurance is a function that is operative across multiple teams. The recognition is that quality problems can be introduced at various stages and there were presumably various opportunities where this problem could have been found. The opportunities to find problems focus mostly on testing done at those various stages.

There is an implied element in that second point as well: that the act of testing is a broad term. You can introduce testing at various points. For example, business analysts can use deliberate discovery or real options (which I argue are a form of testing task if you agree that tests are ultimately about communication). Developers can apply unit testing tools to test at a granular code level. Testers can apply system tests to test at the user-facing level of the application. Project managers can push for iterative beta phases, which is a form of testing by representative users. So while I would argue that it is true that most opportunities to find a problem will come down to testing, it’s not the case that this testing is always done by a test team or even someone with the word “Tester” in their job description.

What this means is a lot of people can influence quality, both proactively and reactively. A QA team is rarely in a position to distill and control all of those influences. A quality assurance function can be established to do so.

This has implications for trying to pin down the one group that is “responsible for quality.” It no longer is just one group that you can point to, at least in all cases. Rather, it’s the collaboration and communication mechanisms that are established that provide for spheres of influence and areas of responsibility. There are things that certain people can have a direct impact on. There are other things that certain people can only have an indirect impact on. Assigning the same responsibility and accountability in both cases simply doesn’t make sense. Finally, there are certain things that certain people can have little to no impact on.

So I would argue that part of the job of good quality assurance and/or test practitioners is to show how subsuming a complex system of activities (“development of a product”) under one conceptual label (“quality”) and then assuming one group is responsible for that is ridiculous. This is a bad way for an organization to look at things. Quality is not that simple. We all have the ability to add bits of quality and we all have the ability to take them away.

It’s really important to keep in mind that the term responsibility refers to the contextually proper sphere or extent of someone’s activities. When you call a team “Quality Assurance” that very name tends to imply that this is the team that is responsible. So don’t do that. Treat quality assurance as what it is: a function. It’s a function that stretches across multiple teams, embracing many roles. When you look at things this way then, yes, quality is potentially everyone’s responsibility but with the recognition that everyone has various areas of quality that they can reasonably influence and others that they have to rely on others to influence. What everyone can do is collaborate and communicate about those areas of influence, learning how to build a shared notion of quality throughout the organization.

When you get to that point, a nice thing happens. You stop asking who is responsible for quality and you keep talking about what quality means and what are the most effective ways, across the board, to make sure the agreed upon level of quality can be consistently met.