This post is mostly a result of a comment from Rahul. He made the comment on a post on Validation and Verification and I think it was a great idea, so here I am with an attempt to distinguish these two closely related and often wrongly used acronyms viz QA (Quality Assurance) and QC (Quality Control).
First the definitions
Quality Assurance – Quality assurance, or QA for short, is the activity of providing evidence needed to establish quality in work, and that activities that require good quality are being performed effectively. All those planned or systematic actions necessary to provide enough confidence that a product or service will satisfy the given requirements for quality. (As per Wikipedia )
Quality Control – In engineering and manufacturing, quality control and quality engineering are involved in developing systems to ensure products or services are designed and produced to meet or exceed customer requirements. These systems are often developed in conjunction with other business and engineering disciplines using a cross-functional approach. (As per Wikipedia)
And here’s a simple version of mine.
QA – Set of processes to ensure that we do a high quality work. These processess are at all level. In s/w world, this could mean a good template to capture requirements, a check-list for testing team which needs to be ticked before we deliver the s/w, code-commenting procedures so that if someone looks at a code which is done by someone else then it makes sense and so on.
QC – Test the desired behavior. Its about testing and finding faults. QC is not about putting a right process but about exercising the process.
Simple and over. Well, mostly but let me go a little deeper and illustrate this difference with few examples
Imagine that you have to test a shopping website. For this project, what would be QA. I wont go into much detail so I would try to distinguish them by listing things which would be QA (and wont be QA)
First of all, the flow of work needs to be documented. This could mean as simple as coder codes and tester tests. Probably we wont call this as QA because it adds no value, its adhoc and it would result in lots of rework, as we will see once we arrive at a better process. So a more evolved way to look at it would be
Product Managers defines the product and lists its aim, objectives, goals and so on. Then UI people break that definition into independent steps, creating screens or UI for each of those steps. Engineering then looks at each of those screens and decide on how they would code it, what is not possible, what can be done better. At the same time, a tester would look at screens and also read the product definition to see if there is a gap somewhere and if there is one then would highlight that. This happens for few iterations and then once things are more clear, Product Manager sort of signs-off on screens, engineering agrees to code it, testers later test it and its all done. While this may sound so simple, it would need a strong collaboration and a lot more team-dynamics to pull it. Assuming that different functions speak different languages and that everyone has a different unit of time, especially when they are expressed in qualitative terms (big effort, minor, major change etc) whats needed here is a process which will drive this. Defining, laying out, and getting it in action of this ‘Process’ is called QA. So at first step, we would expect Product Managers to use some template to define the product. The template is a structured way to define. In absence of template, someone would either write it as a plain flowing text which could be a interesting, funny read but difficult to break or someone can be succinct and just express it in few lines e.g. “Make the best shopping web-site”. The template would ensure that it answers the standard queries of UI folks (do you want it to be very fast loading or do you want it rich?), Eng folks (whats the order of priority, what is most important to you so that we code it first) or testing folks (this is done for what user segment and what kind of h/w do they use so that we can plan our test-bed requirements). When you create such a template and then enforce the usage, thats what is ‘QA’ or “Quality Assurance” because this way you are assuring that we are building quality in the way we are doing things, not in actual thing since that would happen naturally and what ever is left would be taken care by QC.
For the same project QC would ensure that we are testing UI screens to see if it covers the entire definition, that we are not missing things or doing things incorrectly. At this point of time, its mostly validation. When things are coded, we exercise the product to find faults and thats QC. As we develop a product, Quality keeps decreasing. Let me take a step back and emphasize this a little more. Assume that you have just shipped a new version of Autocad. And now you just started to work on the next version. At this point of time, Quality is at highest. As new codes gets checked-in and as you start to find bugs, quality starts to take a hit. This continues till the point when all the new work has been done and only bug fixing is required. At this point of time, the quality is at lowest and then starts to get better. It gets better to with every bug fix and by the time, you need to ship this new version, the quality is at its highest. Now take a deep breath and soak this. During this time, whatever you do to control the quality during this process would fall under ‘Quality Control’. If you do ‘bug hunts’ so that you find all the bugs then its QC. If you do public beta testing then its QC. If you do lots and lots of testing during this time then that is QC.
Ok, so far so good. As I take another deep breadth, I hope that you liked reading this. So next time, you get into a dilemma of whether something is QA or QC then remember this example and it might help you to be more clear on this topic. I am sure some of you would still have cases where its not so easy to distinguish, so feel free to comment or ask questions and we would do this journey together.