Quality Assurance Is Not Quality Control
Quality Assurance Is Not Quality ControlI need to get something straight: QA and QC are different.
Why must I point this out? Because programmers don't seem to get it and use these terms interchangeably.
Testing, therefore is product oriented and thus is in the QC domain. Testing for quality isn't assuring quality, it's controlling it.
There are lots of reasons to ensure the distinction between the two. Easily, the ones that come to mind are:
Please assure me that our QA team knows the right things and the right way. I'm not even convinced they know up from down. And how did they find out the right things and the right way for software engineering, when even AlistairCockburn is still trying to figure it out? -- JohnFarrell
The QA team's job is to see that standards, processes, and policies (or other governing/guiding "writ") are in place and carried out; to recommend and implement improvements to them, and to ensure that the people that need to know about them know about them. QA "audits" or "reviews" are intended to determine the efficacy of these "writs."
It's often easier to understand QA by an example: In one place (a large company with large projects) I've seen QA's role to help project managers plan their projects -- so that the projects follow certain organizational procedures; so that they include the required artifacts, events, and milestones; and so that the projects know what is expected of them and when in terms of reports, reviews, and documentation. As the project progressed, QA would conduct "checkpoints" along the way to see where the project may be developing risks, for example either by progressing beyond where they've got authorization to go, or where they may have need to escalate issues to management. These checkpoints would also be an opportunity to ensure that people who need to be involved are involved at the right times. This approach to QA isn't one that really suits XP, but there are easily ways to adapt such an approach to XP.
Maybe mixups like this are happening because ambiguous terms have been given specific meanings (see: DeGeneralization).
Why would "assurance" mean process-related and "control" mean product-related?
Because "assurance" means that you know you did everything needed to make something that works right, while "control" means that you have no idea whether any or all of your batch o'junk is worth anything until you examine each item. "Just in time" production requires that you are assured your supplier is supplying you with exactly what you need as you need it so you don't have to stop to test each incoming item for defects. See ToyotaProductionSystem or DemingMethod?. (I plan to eventually write a book about how this revolution in manufacturing could be applied to software.) In the case of software, QA means that you know that the code you are making fulfills the requirements, QC is discovering that your process of writing code was not adequate to assure that you didn't create a lot of bugs along with your features. -- ChrisBaugh
One way to avoid confusion is to use more descriptive names: "Product-QA" and "Process-QA".
I have always found the term "Quality Assurance" a curious choice. Why would we want to be assured about quality (made to feel better about it) rather than have quality ensured (guaranteed)?
Assuring quality is about confidence. It's about the *processes* by which we go about doing what we do. Part of that is knowing that we're doing the right things at the right time, and part of it is that we are doing them the right way. This all should be done or known before we start working, not afterwards.
These terms have been defined for us. While it may be 'more right' to redefine them so they're no longer 'degeneralized,' we ought to at least try to ensure everyone has their terms straight when using them.
We may also look at the other areas in which these terms are used. 'Control' is often a term used with statistics, and processes that can be "controlled" with applying the analysis of the statistics. 'Control' is also an active term and has a certain circumstantial connotation. The need to test ("control") is a function of the circumstance of the existence of bugs or lack of confidence. Whereas 'assurance' is a passive term with a more universal connotation. The need to "assure" is a function of building confidence regardless of the existence of bugs and isn't just about bugs, but of the entire effort.
The difference between QA and QC is largely one of power and control. QC is usually as service provided to development (i.e. under the control of development) and is responsible for providing that service. QA expects development to provide services to it (control development) and is not responsible for any result.
The above statement is a symptom of one of the biggest problems in the entire software industry. People don't know what "QA" is supposed to do (as defined in this page). As a result many that do QA, do it wrongly, and many that work with those doing QA incorrectly wind up hating QA because of the lousy experience they had with it.
QA, when done effectively in a project, should not even cross paths with developers except perhaps at the highest levels of management. Or to teach new developers the organizational processes, or teach existing developers about changes to existing organizational processes. And then later QA may interact with development to figure out whether the processes work and what needs to happen to make sure they work better. QA should not be causing developers to do any more work than they need to be doing to develop the work. In fact, most of QA's role should occur with project managers and leaders of other disciplines such as SCM, and QC. (In XP, the idea of SCM or a CCB, or CCA, or a QC "group" doesn't apply in the same way, but there's still a QA role that can be incorporated.)
Another unfortunate characteristic of poorly executed QA is that often in organizations that don't know the first thing about QA the people assigned to QA are rejects from other skills which simply compounds the problem. Again, I'm talking about QA as described here... not QC.
QA ... should not even cross paths with development.
Anyone care to explain this one? What is the purpose of QA if it does not deal with development? I'm afraid "QA as described here" leaves a lot to the imagination.
An edit was made to the paragraph above that may clarify the intent. QA's job is not to inspect code or run tests or test programmers' know-how. If QA is "process" centric, QA shouldn't fit in with the work developers are doing. QA folks should be "process" folks not "product" folks. As such, QA's job should happen before and in the aftermath of product development, and less to do during development. The purpose of this page is to separate QA from the concept of "testing." A discussion of what QA (QualityAssurance) really is seems to be brewing. Which is something this page is not a good place for. Without proper definition, QA rightly so "leaves a lot to the imagination."
So, define it already. It is not enough to say QaIsNotQc, you need to also say what QA is. Also, is there really some deep distinction between the two, or is this just some nit-picking intended to preserve a QA role when none is needed?
I have to agree with the prior comment that the terms are very confusing. Even though they are commonly used, I think we'd be much better off if they were not. Part of the problem is that these terms were taken from manufacturing paradigms. QA dealt with manufacturing processes, while QC inspected the manufacturing output to verify that it was acceptable. In the manufacturing environment you analyze, design, and implement once and then crank out many essentially identical products. This is very different from the software environment where the analysis, design, and implementation happen on each product, and then you start over for the next iteration.
In a software environment, "Quality Assurance" does not assure quality. Rather, they assure that a process is being followed, which is very different. The process, if it's a good process, will increase the probability that there is a quality result. It will, presumably, make sure that requirements are communicated, traced, planned for, scheduled, etc. The "Quality Assurance" role will likely also collect metrics that it can then use for process improvement. However, this group could do its job and still have the organization's product be low-quality. Therefore this function would be better termed "Process Management."
Similarly, "Quality Control" does not control quality. Rather they measure quality, by verifying that what was implemented matches the requirements. Certainly there's a feedback loop, as any defects will be reported and presumably fixed, thus increasing quality. But this group doesn't really control anything. It would thus be better termed "Requirements Verification," although I find the term "Product Test" more concise.
Calling these functions Process Management and Product Test removes any ambiguity or confusion. And calling them by these names does not impact your ability to get ISO 9000 certification or achieve a CMM level. Those require certain things to be done or documented, and require certain functions to be executed by the organization, but absolutely do not require specific organizational names.
-- JimSeidman?
Well Said!!! -- HillelGlazer
I'm currently performing a quality assurance role on a software project. This has been a first for me and I haven't spent a great deal of effort find out what quality assurance is "supposed" to mean, because to me it is clear. I'm supposed to assure the quality of the product and customer satisfaction. That doesn't mean reassuring people that quality exists, it means stepping in wherever I see an opportunity to add or ensure quality. For this project it has meant a lot of things - clarifying requirements, documenting new requirements, facilitating communication within the development team, and yes, testing. But not just testing software, testing requirements, testing understanding of requirements, testing the schedule, etc.
If it is difficult to define what quality assurance is or should do, perhaps part of that is because it likely will vary from project to project. If you spend a great deal of effort trying to apply some "this is what I'm supposed to be doing" process to a project I'd guess a lot of your effort is going to go into dotting i's and crossing t's that could have better been spent contributing something useful to the project. Which is not to say you shouldn't learn QA techniques or processes, only that QA requires the ability to analyze and respond logically to the needs of the environment and situation in which it is being performed.
EditText of this page
(last edited March 28, 2014)
or FindPage with title or text search