So it’s obvious we need quality assurance, right? Okay, it’s true that quality is a dynamic concept that is contextual and situational. And, in a way, you can never really know the “actual” quality of an application in some universal sense. This is partly because quality is a value judgment based on the eye of the beholder. And it’s probably true that quality is not open to some absolute definition. (Similar to how other abstract words like justice, beauty, democracy, and so on are not absolute concepts.) But still. We obviously need some way to assure this beast we call quality. We obviously need a team called Quality Assurance.

I mean, it’s obvious. Err … right?

So I said a few possibly controversial things depending upon how you view the world:

• Quality is a dynamic concept that is contextual and situational.
• You can never know the “actual” quality of an application in some universal sense.
• Quality may not be relatable to some absolute definition.

I stand by all that. However I think testers in particular need to keep in mind that perceived quality is the result of some form of testing. Via a variety of test methods, you can derive an informed assessment of test results. Those results can be compared to expectations. Those expectations are what validate an existing notion of quality. This means that “quality” is an abstract that can be made concrete; “quality” is something that can be related to different things that are assessed in some fashion: usability, maintainability, functionality, efficiency, portability, etc.

But “obviously” this starts to go way beyond the tester role.

While the major element of any quality focus is predicated on some notion of testing, thinking about quality and what it means is a slightly higher-level topic than the more granular nature of testing concepts, such as “what’s a test case?” or “what level of detail should my tests go into?” When you’re thinking about testing in relation to the wider concept of quality, you’re often thinking of what value testing brings and how it brings that value. (Check out The Value of Testing Relative To Quality.) This, in my experience, leads into areas that some people consider “obvious.” In those cases, however, I’ve usually found that people are translating what’s obvious in testing concepts to what they think is obvious in quality concepts. And that’s not always the case.

I trust the reason for the above quote is now … “obvious.” So let’s talk about this.

The “practice of quality assurance” — amorphous thing that it may seem — is “obviously” auditing, monitoring, and testing. That’s basically what quality assurance is. What the practice of quality assurance does or how it functions is the means by which you do that auditing, monitoring, and testing. I think it’s important to recognize that testing (as a discipline, not a role) is so much a part of quality assurance that it’s really inseparable. I say that because you test everything.

Wait, everything? Really?

Well, let’s consider the context in which you usually test.

Your company is usually in the position of making some sort of product or service. That product or service will be part of various projects: either to create new functionality for the product or to modify existing functionality. There’s also the idea that your company might create an entirely new product that will have its own projects applied to it. So, your quality focus overall is “obviously” not just looking at the product itself but also the means by which that product is produced.

That was obvious, right?

Looking at how the product is produced usually boils down to looking at the project as whole. And that usually boils down to a life cycle of some sort. That life cycle will consist of the means by which the product is produced: requirements documents, design specifications, test plans, version control systems, source code, build tools, executable binaries, finished web-based applications, executable tests, and whatever else you have thrown into the mix.

So here’s an “obvious” thing.

This is “obvious”… One major goal of quality assurance should be to get a testing aspect into the life cycle at all stages — from requirements on down to post-implementation and post-release.

At each phase of the life cycle, an effective quality assurance process would be advocating for some sort of testing. Perhaps you’ll be testing documents (to check for things like consistency); perhaps you’ll be testing code itself (in the form of code reviews or inspections); perhaps you’ll be testing the direct execution of code without a front-end (API testing, for example); perhaps you’ll be testing the full system, after all the parts of it have been integrated and work with a front-end (system testing); and perhaps you’ll only be testing to be sure that new functionality did not adversely affect existing functionality and is not itself broken (regression testing).

Note that I didn’t say someone in a tester role would necessarily be doing all those things. Important point there. (I’m sure it was “obvious” though.)

Let’s not forget, amidst all this testing, that quality assurance is also about auditing and monitoring. The monitoring is pretty simple, in concept, in that you’re basically going to be monitoring the functions of what quality assurance is doing. Interestingly enough that monitoring will mainly be via testing of some sort. Quality assurance can also be about establishing certain processes, such as a bug tracking solution or a standard change control process. So monitoring, in that sense, will be making sure that the process is not only defined but, as defined, is being used.

That’s all “obvious,” right?

What about if the process is being used but it’s not working all that well? Or what if your testing process, though established, is not catching bugs? That’s where the auditing comes in. You have to audit anything that you’re doing in order to make sure that what you’re doing is effective. In other words, it’s one thing to be doing a process. It’s another thing to be doing the right process, where the “right process” is the one that’s effective for your situation. That’s a central function of quality assurance that gets wrapped up in all this — but often forgotten and thus perhaps not so obvious.

So here’s another “obvious” thing.

This is “obvious”… Quality Assurance not only determines if you’re doing the correct things but it determines what “correct” means in the context of your company, given staffing issues, technology issues, market realities, sales needs, etc.

To be sure, quality assurance probably doesn’t have sole authority to determine what is “correct” and I would argue that’s a good thing. Quality assurance should, however, make sure that others are thinking about what “correct” means. Obviously, right?

I’ll be the first to admit that it’s hard to sum up everything about a quality assurance focus, but there’s one operating heuristic I often tell people to at least keep in mind.

This is “obvious”… We should think about combining a test life cycle to the project life cycle for each product that you’re ultimately responsible for providing information about.

That testing life cycle will contain processes for monitoring and auditing various aspects of the life cycle as well as looking at what’s being produced at each part of the life cycle. It may be requirements in one phase; it may be source code in another; it may be a user’s guide in yet another.

Everything I said up to this point was about quality assurance inside of a given life cycle. That’s a fairly vast area in itself but that focus also implies the distinction that there is an outside to the life cycle. Quality assurance can, in fact, have another aspect that is outside of specific life cycles in general and that serves to establish what the life cycles in fact are. Or quality assurance can provide criteria for how projects can be established, such as by imposing necessary entrance criteria or checklists for a project to be started up in the first place. This is where quality assurance and other disciplines like project management and product management start to “obviously” overlap. The degree of overlap as well as the degree to which various roles participates in these actions is heavily dependent upon the nature of the company, its organizational hierarchy, and its general business practices.

So I think some key things to understand are:

• There are project life cycles and product life cycles.
• Quality assurance can operate within both of those things.
• There is a business life cycle that is outside of strict project or product life cycles but that can dictate how those life cycles function.
• Quality assurance can also operate at that level.
• Quality assurance is about three main activities: auditing, monitoring, and testing.

Regarding the first four points in that list, I think it helps to think of a Quality Assurance Framework, for lack of a better term. A framework in software terms is usually a skeleton into which an application can fit. The point of a framework is to provide some sort of reusable, common structure that can be shared. Developers, for example, usually incorporate the framework into their own applications and extend that framework to meet their specific needs. A test framework might be used by testers in a generally similar way. What I’m talking about here is more of a conceptual framework, but a framework nonetheless. In this case, I’m talking about a framework that defines, prioritizes, quantifies, and measures any processes and techniques throughout a product life cycle to permit early detection and corrective actions of deficiencies that significantly reduce impact on cost and schedules. I’m talking about a framework that constantly seeks proof that a product is being delivered that adds demonstrable value to customers.

This is “obvious”… The basic mantra of the quality assurance function: advocate, argue, assert, defend, escalate.

I also want to focus on that last bullet point a bit, regarding the “three main activities.” While I think that point is true it’s also similar to misleading phrases like “McDonald’s has served over ten hamburgers.” No doubt it’s an accurate statement but it also misses some important details of scope.

At its most basic, the act of “assuring quality” is one of degrees, rather than of one action or even one set of actions. “Assuring quality” (i.e., the “act” of quality assurance) manifests as a set of activities designed to evaluate the processes by which products are developed or manufactured. Put differently, quality assurance is a function that identifies, documents, and reviews for improvement the processes that deliver products.

The “act” of assuring quality is an act that plays out over time and is about balancing methodology, leadership, and technology. Quality assurance is about taking into account human factors as well as technological ones. The emphasis with “assuring” quality should be more on process than the product because a stable, repeatable process is one in which quality can be an emergent property that partly manifests itself in the creation of products like software applications or client-facing services.

With all this, I guess it would be “obvious” that quality assurance is always optimizing. The process is always in transition and never stopping at one point. There’s never a point at which optimization is necessarily achieved; only points where an organization with a quality assurance focus (not necessarily a quality assurance team!) is able to say that its process (in relation to a given product) is optimized under its current restrictions or limitations. This means that no one particular quality process or quality methodology, however well thought out and executed, can guarantee quality over time. Customer requirements, technology, and business realities change much too swiftly for just one process to suffice for all situations and contingencies.

This is “obvious”… It’s important to understand the quality assurance focus as a pattern of actions within the context of continuous improvement.

There’s kind of a critical point here. I’ve been avoiding saying the phrase “Quality Assurance team.” That pattern of actions I just mentioned involves lots of people, not just testers. If there is a true “QA team”, the it should be composed of various people, such as project managers, testers, business analysts, developers and so on. Testers alone are not going to assure quality. (See Testers Relax … You Don’t Really Assure Quality.)

In fact, you know you’re humming along when you don’t even really speak about a “QA team.” Rather, you speak about how your organization performs quality assurance. At all levels. And with all people. The goal of those who participate in quality assurance should be to understand the problems as they exist to such a degree that testing tasks are formulated so that, organizationally, it’s possible to reactively eliminate or proactively prevent the right problems. By “right problems”, I mean those that would most cause people in the company to say they don’t have confidence in the product and those that, if allowed to go on, would cause the most problems for the organization based on the organization’s notion of value and, of course, user perceptions of the product.

So does literally everyone participate? Is quality everyone’s responsibility? Well, see Is Quality Really Everyone’s Responsibility? for my thoughts on that. What I’ll close by saying is that I think people need to understand it’s very often the case considered “obvious” that a Quality Assurance department or team should exist. It’s also considered “obvious” what they should be doing and how they should be doing it. And, yet, it’s very possible that a Quality Assurance team is ineffective because unless there’s some familiarity with the concepts I talked about here, the nature of what is and isn’t “obvious” can become a bit problematic.

Obviously.