Quality Assurance and Quality Control: Two Complementary Pillars

QA vs QC: Process or Product?

In many software projects, quality is often discussed as if it were an abstract concept or a catch-all term where everything fits. Within this ambiguity, the terms Quality Assurance (QA) and Quality Control (QC) are used far too frequently as synonyms, when in reality they describe distinct and complementary functions.

Equating QA with QC is not merely a terminological issue; it is an operational risk. When the boundaries between the two become blurred:

• Vague responsibilities are generated.

• Incomplete processes are designed.

• Project quality ends up relying entirely on end-of-cycle testing.

The result is usually predictable: deliveries with more risk than necessary, excessive dependence on “last-minute heroes”, and difficulty explaining to the client what is actually being done to guarantee quality.

Distinguishing precisely what QA is, what QC is, and how they relate allows for the construction of a robust quality strategy. QA focuses on the way work is done. QC focuses on checking the result of that work. Only when both are well-defined and coordinated can we speak of a real guarantee, both technical and procedural.

What is Quality Assurance

Quality Assurance (QA) is the framework of processes, standards, criteria, and practices that an organization establishes to ensure that software is built in a controlled, predictable, and repeatable manner. Its primary purpose is to prevent defects before they reach the product and to reduce variability in the way of working.

QA operates on the teams’ way of working. It defines:

1. How requirements are gathered and approved.

2. Which design and code standards must be respected.

3. How changes are managed.

4. How deliveries are planned.

5. Under what conditions a functionality is considered finished (Definition of Done).

All of this does not focus on a specific project but constitutes the foundation upon which all the organization’s developments are supported.

In a mature QA approach, several recurring elements are usually found:

• Clear quality policies: They set coding standards, design criteria, security rules, and requirements for accessibility or regulatory compliance.

• Formalized processes: They describe in detail how to move from the initial idea to the deployed software.

• Explicit definitions: When a requirement is ready for development and when a task is truly finished.

• Delimited roles and responsibilities: It is known who reviews requirements, who validates designs, who reviews code, and who authorizes a deployment.

Process reviews and audits are also part of QA. It is not just about looking at the final product, but about analyzing how the work was done: what incidents occurred, what decisions were made, what steps were omitted, and what risks were accepted. From this analysis, continuous improvement is driven through adjustments in procedures, specific training, or revision of standards.

In day-to-day practice, the presence of a well-implemented QA system is evident when development doesn’t begin without clear requirements, when code isn’t integrated without prior review, when a version isn’t deployed without an associated test plan or a defined rollback protocol, and when no project starts without an explicit quality strategy.

What is Quality Control

Quality Control (QC) focuses on the product being delivered. Its mission is to verify and validate that the developed software meets the agreed functional and non-functional requirements, as well as the quality standards adopted by the organization.

While QA tries to prevent defects from appearing, QC handles detecting the defects that have materialized. To do this, it relies on verification and validation activities performed on the product itself or on increments of it. The goal is not just to find errors, but to provide an objective view of the real state of each version intended for release.

QC is mainly specified in the design, execution, and maintenance of tests. It includes:

• Unit tests.

• Integration and system tests.

• Regression tests.

• User Acceptance Testing (UAT).

• Performance, security, compatibility, or accessibility tests.

These tests can be manual or automated, and in practice both approaches are usually combined to optimize coverage, depth and cost.

Another pillar of QC is traceability against requirements. Each test case is linked to one or more requirements or user stories, allowing us to know which parts of the system have been verified and with what result.

Defect management also belongs to the scope of QC. It involves recording each incident, classifying its severity and priority, following its life cycle until resolution, and documenting the root cause.

Finally, QC generates quality reports that allow for informed decisions on whether a delivery is ready for production.

Fundamental Differences Between QA and QC

Although QA and QC are part of the same quality management discipline, their approaches are different:

1. Preventive vs. Detective Approach:

QA acts on the process and is preventive in nature. Its key question is: Is the work being done in the right way so that the result is reliable?

QC acts on the product and is detective in nature. Its key question is: Does what has been built actually work as expected?

2. Deliverables:

QA produces: Policies, processes, standards, templates, and service agreements. QA designs the work system.

QC produces: Test cases, execution evidence, defect logs, and quality reports. QC measures the result of that system on the actual product.

3. Impact:

A good QA translates into organizational stability and less dependence on specific individuals.

A good QC translates into fewer visible defects for the user and more confidence in each released version.

It is not about choosing between QA or QC, but about recognizing that complete quality demands the balanced presence of both.

How QA and QC Complement Each Other in the Project Life Cycle

The relationship between QA and QC is clearly understood by going through a project from start to finish.

Discovery and Analysis

In the initial phases, QA defines how requirements will be gathered, documented, and approved. It indicates what is considered a well-formed requirement, what information it should contain, who should validate it, and how it is prioritized.

At the same time, QC can start collaborating by transforming these requirements into test scenarios and clear acceptance criteria. This early collaboration reduces ambiguity, avoids misunderstandings, and ensures that what is defined by business will be verifiable in later phases.

Design and Architecture

During this phase, QA ensures that established design and security standards are applied, that the resulting solution is consistent with the organization’s strategy, and that the system will be testable (observability, modularity, isolation of dependencies).

QC provides the practical view of what tests will be necessary, what workloads should be simulated, which integrations might be more fragile, or what combinations of devices and operating systems need to be considered.

Development

Here, QA defines the code and change workflow. It establishes branch usage, conditions an integration request must meet to be accepted, what static analysis tools should run, and what minimum code quality thresholds are required.

QC, for its part, collaborates in the definition and execution of unit and integrated tests, develops and maintains automated functional and non-functional test suites, and stays involved in the continuous validation of increments.

Validation and Pre-production

When the project enters this phase, QA marks the global testing strategy: what types of tests will be executed, what environments will be used, what data will be employed, and what entry/exit criteria each phase has.

QC executes that strategy, collects results, manages incidents, and builds reports reflecting the real state of the version: what works, what doesn’t, what parts could not be tested, and what residual risk remains if the decision to release is made.

Deployment and Operation

In the final phase, QA defines production deployment procedures, rollback plans, the way to record incidents, and post-incident review dynamics.

QC executes smoke tests after a deployment, checks that critical functionalities behave as expected in the real environment, and analyzes defects detected in production to feed continuous improvement.

In this way, QA designs the framework and QC provides real information on how the product behaves within that framework. That information flows back into the QA scope to adjust processes, standards, and practices. The result is a cycle of continuous learning.

Technical Quality and Procedural Quality:

A Double Guarantee

When a client asks for project guarantees, they are not just referring to the software working correctly at the time of delivery. What they are really looking for is the security that the service is provided under a solid work system, which reduces the probability of serious incidents and allows for a quick and orderly reaction.

The combination of well-implemented QA and QC allows for offering this double guarantee:

On the technical level (QC): A clear testing strategy, the presence of automation at the right levels, the use of code standards, and the existence of monitoring and alarms provide a very effective barrier against critical defects in production. Furthermore, when a problem appears, having traces and metrics facilitates root cause analysis.

On the procedural level (QA): The existence of defined processes, clear roles, and documented acceptance criteria provides stability and traceability. How work was done on each version can be reconstructed, what decisions were made, and what risks were assumed. This reduces dependence on undocumented knowledge (“tribal knowledge”) and allows for replicating best practices.

QC provides confidence in the product delivered today. QA ensures that the way of working allows for continuing to deliver products with the same quality tomorrow.

Metrics and Quality Governance

For QA and QC to be more than just good intentions, it is necessary to measure and govern.

From the QC perspective, it is useful to observe indicators such as:

• The number of defects per version.

• The proportion of critical defects detected in early phases vs. production.

• The stability of regressions.

• Functional coverage achieved by automated tests.

• Average time for incident resolution. This data allows for evaluating the level of risk involved in each delivery.

From the QA perspective, metrics such as these have value:

• The percentage of requirements entering development that meet the readiness criteria.

• The amount of code integrated without prior review.

• The volume of rework due to poorly managed changes.

• The number of incidents associated with process non-compliance.

• The degree of actual adoption of the defined standards. These indicators allow for identifying at which points in the process problems originate.

Quality governance consists of reviewing these metrics with an appropriate cadence, analyzing them in context, and making specific decisions based on them. This can translate into adjusting the testing strategy, reinforcing training, or simplifying processes.

Operational excellence requires the strategic integration of Quality Assurance (QA) and Quality Control (QC). Operating only with QC entails high corrective costs due to its reactive nature, while limiting oneself to QA generates theoretical frameworks without empirical validation. By unifying both approaches, quality stops being circumstantial to become a robust, quantifiable management system oriented toward continuous improvement.