What’s the first thing that comes to mind when you hear the terms “Quality Assurance” (QA) and “Quality Control” (QC)?
Over the many years, we’ve spent developing software, we’ve regularly used the term “QA” when referring to a complex of actions that have to be carried out at every single stage of a digital product’s life cycle. That said, we barely use the term “QC”, since it’s not so well-known. So what do these two notions mean, when do we tend to mix them up, and why is it important to know the difference between QA and QC? Let’s find out.
A bit of personal experience
We often get software project ideas from clients, who do not understand why QAs are required in the first place, saying that they can test the product by themselves. They assume that QA is merely the process of testing the product for defects, and that it takes place only when a new feature is released – that is a common myth, which prompts other companies to dismiss QA services in favour of doing QC only. Perhaps, this happens due to misinterpreting the meaning of the terms, which may result in having to make expensive corrections to the end product because of the previously overlooked disparities in the project documentation.
The client often assumes that QA is a “smoke test”, or a type of testing that determines whether the main project features function properly, with some “research testing” also thrown in for maximum test coverage.
When we discuss QA with our Potential clients, the bare minimum of information we provide is:
|Criteria||Types of testing|
|Types of tests by coverage (by depth)||Smoke test|
Minimal Acceptance Test (MAT, Positive test)
Acceptance Test (AT)
|Test activities (types of tests by coverage)||Defect Validation|
New Feature Test (NFT, AT of NF)
|Types of penetration tests||Black box|
|Types of tests by the automation level||Manual|
|Types of tests by the degree of component isolation||Unit/component (modular)|
|Types of tests by the level of preparation||Intuitive testing|
|Types of tests by time and place||User Acceptance Testing (UAT)|
|Types of tests by the object of testing||Functional testing|
|Non-functional testing||GUI testing|
Productivity testing or load testing
This is far from a full list of all the QA services carried out during development. Let’s try to figure out what the process itself implies, below.
Quality Assurance vs. Quality Control (QA vs. QC)
Quality Assurance is a series of measures that encompass all procedural and technical stages of development, and involves the use of numerous testing tools for ensuring maximum possible quality and customer satisfaction upon the product’s release.
In turn, Quality Control means product testing and the ability to influence certain testing processes (planning calibration, process refinement, relevant reports preparation).
The difference between them lies in the fact that QC is a part of QA. While QA is oriented at the testing process and its elements, QC is oriented towards the execution of testing by launching the program and finding defects that need correcting.
Several questions arise when we try to get to the essence of QA and QC:
- Who is responsible for QA?
- Who is responsible for QC?
- What does a QA engineer do, and how is it different from what a QC one does?
- What responsibilities and rights do QA and QC have?
Quality Assurance (QA)
So, generally speaking, Quality Assurance can be described as “the process or the result of forming the necessary qualities and characteristics of a product during its development” (the full definition is a little broader, but we’ve outlined the most crucial part).
This definition works for software products, as well as for any man-made goods, since all of them have certain quality quotas or performance expectations.
We’ve already determined that QA is “the process or the result”. Let’s split the whole definition into three parts and then go through them point by point.
- “the process or the result” – as mentioned above, it’s a process-oriented approach focused on the process of testing itself and its elements, rather than at the product;
- “forming the necessary qualities and characteristics of a product” – Quality Assurance is closely tied to the software development life cycle (SDLC).
Let’s use the Waterfall model as an example:
- the start features requirement analysis;
- the middle has several stages dedicated to solving concrete tasks that arise over the course of the dev cycle;
- the final result is an end product that meets the client’s initial requirements.
QA plays an important role over the course of the whole SDLC. You can learn more about SDLC and STLC in our What is Software Testing Life Cycle article.
Introduction of testing specialists during the requirement phase is considered good practice. The QAs will be able to discern logical inconsistencies in the client’s requirements: say, possible conflicts with product filters in cases where some of them belong to overlapping categories, or the logic behind the parameters at the check-out. Conflicts in admin rights distribution are very common, as well as issues with returned merchandise authorization (RMA).
C) “during its development” – Considering point B), we can infer that “during its development” refers to the development team’s proactivity. This is determined at the requirement stage, and includes the following activities:
- Product requirement analysis;
- establishing testing standards and documentation (this also includes using test management systems (Testrail), bug-tracking systems (Jira), document management systems (Confluence));
- writing test cases and implementing support methods for their actualized versions (involves deciding who will be responsible for keeping the checklists up to date and reviewing their contents, as well as the standards for checklist modification;
- planning sprint, increment, and iteration testing;
- evaluation of the testing tasks at hand (points 4 and 5 both have to do with test planning in relation to the dev crew itself: task evaluation and decomposition, their allocation between various QA team members);
- project testing;
- testing data analysis;
- planning and implementation of testing quality improvement methodologies (points 8 and 9 are interconnected and are equally important. Simply put, you have to figure out why a bug was missed, how critical it was and how to avoid encountering it in the future);
- establishing testing report standards (this refers to the report that the QA engineer compiles for the client after the final stage of testing or after a certain period of time).
Quality Control (QC)
Referring to the start of the article, let me remind you that Quality Control is:
- Quality Control implies testing the product as a whole, with the option to influence the testing process (planning calibration, process refinement, relevant reports preparation)
Essentially, you can define QC as “product quality as it is here and now”. QC specialists check the solution for bugs and mistakes. The main goal of a QC specialist is finding and fixing the bug.
QC is directly tied to testing, and these days, the notion of “testing” often extends past being a separate step in the overall development process. This happens because of projects becoming more and more complex with time, which in turn leads to Quality Control gaining its own identity, with its own unique tools and metrics.
By separating these two notions, we can identify Testing as a completely new element within QC, complete with its own clear definition:
Testing is the process of comparison between the expected and the factual result with the added responsibility of writing test cases and keeping them up-to-date, plus extra low-level activities.
Let’s see the difference between Testing and QC by using the same online store example.
It’s the second iteration of our online store, and we’re in the pre-release stage.
The tests for the first version’s functionality are automated at this point.
The previous version’s functionality is tested automatically – that’s Quality Control.
The functionality new to the current iteration is tested manually – that’s a level of Testing.
The main difference between QA and QC
So, what’s the difference between Quality Assurance and Quality Control?
- It’s a single mechanism made up of several parts, which looks like this:
QA occupies the topmost level, QC takes the middle, and Testing is on the lowest one – but it’s not separate, and acts as an integral part of QC.
Of course, the levels differ in both their meaning and function, where:
- QA represents the procedural part of testing (planning, integration, evaluation);
- QC represents product testing in general and can influence testing processes (planning calibration, process refinement, relevant reports preparation);
- Testing is the process of verification that the expected result corresponds to the factual one with the added responsibility of writing test cases and keeping them up-to-date, plus extra low-level activities.
All these can be summarised in a table:
|Criteria||Quality Assurance||Quality Control||Testing|
|Essence||A series of measures that encompass all procedural and technical stages of development, and involves the use of numerous testing tools for ensuring maximum possible quality and customer satisfaction upon the product’s release.||Represents product testing in general and can influence testing processes (planning calibration, process refinement, relevant reports preparation).||The process of verification that the expected result corresponds to the factual one with the added responsibility of writing test cases and keeping them up-to-date, plus extra low-level activities.|
|Main focus||The testing process and its elements, rather than the product||The execution of testing by launching the program and finding defects to correct||Completing test cases and comparing the factual result to the expected one|
|Approach||Process-oriented approach||Project-oriented approach||Project-oriented approach|
|Moment of emergence||Preventive approach||Process refinement||Preventive action|
|Structure||Consists of the STLC stage subprocesses||Consists of many QA subprocesses||Consists of many QC subprocesses|
You can experiment with complex QA or pure QC as much as you want, but keep in mind that by dismissing anything, you invite bugs into your project.