About the Site | What's New? | Disclaimer | Site Map | Fun Stuff
Like most concepts to be defined, in any attempts to define Quality Assurance (QA), it pays to consider that in light of what Quality Assurance does. A common thought is that Quality Assurance is there to either "fix the defects" or "prevent the defects". Those statements are true, as far as they go. However, QA does a lot more than just these two statements. QA, if implemented correctly, provides the means by which defects (in all types of products, both executable and non-executable) are proactively mitigated as well as provides the means by which defects can be found after their introduction - such as via robust and viable verification and validation procedures.
Fundamentally, QA is about change and process. It is about balancing methodology, leadership, and technology. It 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. Quality Assurance can be treated, in some ways, as a science. We can treat the products we are given, and the processes used to generate those products (such as the standard development lifecycle) as theories. The theory is supposed to explain a lot (i.e., work well in a given context). To show that the theory is valid, we have to show not just that it works - but also show the flaws it might contain. Find enough fatal flaws and the theory potentially crumbles. (By the same token, a few flaws here and there may not crumble a theory - just show that it needs some work.) But how do we show that the theory is valid? In other words, how do we find those flaws? That is the role of the QA effort, which aims to be as proactive as possible.
Again, you are dealing with change and process, usually together because the change that is going to be implemented will generally manifest itself in a series of processes that, taken together, serve as a type of methodology. It is the act of delineating and establishing this overall quality methodology that I refer to as Quality Engineering.
So Quality Assurance, with what was just said here, is meant to be a proactive means of engineering quality into a product by concerning itself not just with the product, but that which produces the product. Here "proactive means" refers to different processes that, taken together, work well for the organization as a whole and that constitute a contextual methodology.
That begins to get to the heart of the matter because QA is about the discovery of or creation of underlying contextually relevant processes - not necessarily acting in accordance with pre-existing processes without any thought as to their validity. By the same logic, Quality Assurance is not simply there to sweep away all existing processes under the assumption that they do not fit a new "master plan." The key point is that it is a role of Quality Assurance to establish, or help establish, processes if none exist or monitor processes that do exist. Along with that, if existing processes are proven to be not effect, it is the role of Quality Assurance to advocate the removal of those processes and the establishment of new ones. How much of all of this is done depends on the role of QA within the organization and how proactive the quality effort is as well as how focused it is. Essentially, Quality Assurance can either be shaped by an organization or do some of the shaping of the organization. It can often be a delicate balancing act. This balancing act is best done within a quality framework.
The idea of a framework that balances QA's role within an organization can be considered as a framework that defines, prioritizes, quantifies, and measures those processes and techniques throughout the product lifecycle to permit early detection and corrective actions of deficiencies that significantly reduce impact on cost and schedules. There are many actions that can be considered within this context, such as:
What these bullet points capture is the basic mantra of the quality effort: advocate, argue, assert, defend, and escalate. This framework makes up the basis of the methodology that will be employed in a quality initiative. It is the manner by which quality is engineered into a product as much as is possible.
We can look at the definition of Quality Assurance, as we did with quality, in a more systemic viewpoint. Consider that we can say of Quality Assurance that it is a systematic pattern of actions that attempts to assure that all software products released are (a) stable, (b) perform as described in any product specification(s), and (c) meet target customer/user needs and expectations. That is good as far as it goes but that rough definition subsumes the process a little too much. Any definition of Quality Assurance has to take into account that, at its base form, the act of assuring quality 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.
I have often defined Quality Assurance as such:
"A systematic pattern of actions that is constantly optimizing productivity, communication, and value within an organization in order to achieve the aim of measuring the attributes, properties, and characteristics of a product in the context of the expectations and needs of customers and users of that product."
This also corresponds to my operational definition of quality itself. The key concept in this definition is, in one sense, the product. However, the production of something implies the existence of a process by which that something is produced. Thus, in reality, it is this process that we are concerned with. The process will impart attributes, properties, and characteristics to the product that it helps create. And that is what we are measuring. We map the product to the process and realize that a faulty product probably relates back to a faulty process. The role of QA is to assure that this process (or set of processes) is documented, followed, reviewed, and improved. Once processes are identified and functioning, then the role of QA also expands to establishing measurements for the purpose of identifying process weaknesses, which translate into product weaknesses. This starts to suggest a modification of my above definition:
"A systematic pattern of actions that are constantly optimizing productivity, communication, and value within an organization in order to provide confidence that processes are established and continuously improved in order to produce products that meet specifications and are fit-for-use within organizational and competitive constraints."
With this definition, the "patterns of action" are policies and procedures and include such things as facilitation, training, measurement, and analysis. The means by which confidence is provided is by various quality measures put in place throughout the lifecycle of the product.
For me QA is the ultimate "run anywhere" sort of concept because it is, if done right, designed to tailor itself to its host organization (much like a benign virus) and work within that to achieve quality to whatever degree possible; basically to spread its tendrils throughout the organization in a Body Snatchers-like fashion - sometimes utilizing what already exists, sometimes modifying what already exists, and sometimes establishing something that does not exist. Quality assurance is process management with the aim of achieving the quality appropriate to the product. As Boris Bezier has said quite adequately: "Quality assurance, as an over-all actitivy is a process improvement and optimization activity. Quality Assurance focuses on and looks at process, not product. If you want real quality assurance and real quality control in your organization, your first Quality Assurance task should be to assure that everyone, especially management, understands the difference."
We also have to remember that when you define Quality Assurance, the assumption is that the "Quality" in that term will refer to the definition of Quality that you have. In the case of the standard dictionary definitions you basically have: "[Superior in Kind] Assurance" or "[Degree or grade of excellence] Assurance." The issue is that we often have to make the idea of quality more concrete within a given venue. The whole point of a discipline is to restrict the meaning of this very broad concept. Otherwise it becomes a case that anything that someone subjectively considers quality is, ipso facto, quality. A few other ways to think of quality assurance:
"The policy, procedures, and systematic actions established in an organization for the purpose of providing and maintaining a specified degree of confidence in the processes by which the organization develops, maintains, supports, and tests a given product."
"The set of support activities (including facilitation, training, measurement, and analysis) needed to provide adequate confidence that processes are established and continuously improved in order to produce products that meet specifications and are fit for use."
The discipline of Quality Assurance is conceptualized in relation to a set of basic theoretical distinctions. One common such distinction is that of verification and validation. Verification refers to the process whereby the capabilities of a software application are tested against its engineering/marketing specification and requirements. Most testing consists of verification. With verification we are asking: "Are we building the product correctly?" Validation, on the other hand, is the process by which software is tested against the expectations of its intended customers. Think of this as a test of the application's specification rather than a test of the application itself. As Brian Marick has stated: "What if the product works exactly as intended, but what was intended is wrong?" So with validation we are asking: "Are we building the correct product?" Both processes can be going on at the same time. For example, a given tester can be noting both whether a given feature behaves according to the specification but also whether he or she thinks the feature as specified would meet a customer's or end-user's needs. Validation is not carried out systematically within many organizations primarily because testers have to rely on their own experience and intuitions to stand in place of the customer and thus bias of a sort is inevitable. But often this type of in-house testing is the most valuable kind of testing. It is also the reason quality assurance or control staff will sometimes represent to marketing the inadequacy of a particular feature, even when the feature meets the product specification or design documentation. We have to realize that the practice of verification and validation has two main objectives:
Some people like to consider Dynamic Verification which, they say, is concerned with exercising and observing product behavior (which is basically what we mean by reactive testing.) Others like to consider Static Verification, which is concerned with the analysis of the static system representation, in various guises, to discover problems. (This speaks more to proactive testing.)
For questions or comments on the site, contact Jeff Nyman.
The material on this site, unless stated otherwise, is considered Open Content
and is distributed under the GNU Free Documentation License.
GlobalTester, TechQA, Copyright © 2002 All Rights Reserved. (Labelled with ICRA)
