Si estás estudiando QA o preparando una entrevista, es muy probable que en algún momento te hayas preguntado qué diferencia hay exactamente entre QA y QC. Y si te digo la verdad, es uno de esos conceptos que mucha gente del sector usa mezclados sin darse cuenta.
En este artículo te lo explico de forma sencilla, con ejemplos reales y sin tecnicismos innecesarios.
La explicación rápida
QA (Quality Assurance) significa aseguramiento de la calidad. Es un proceso preventivo — su objetivo es evitar que los defectos aparezcan desde el principio.
QC (Quality Control) significa control de calidad. Es un proceso reactivo — su objetivo es encontrar defectos en el producto una vez que ya está construido.
Dicho de otra forma: QA trabaja para que las cosas salgan bien desde el principio. QC comprueba que efectivamente han salido bien al final.
La analogía que lo explica todo
Imagina una fábrica de galletas.
QA sería establecer los procesos correctos antes de empezar a fabricar: asegurarse de que los ingredientes son de calidad, que las máquinas están calibradas, que los operarios siguen el procedimiento correcto y que hay normas de higiene. Todo lo que se hace para prevenir que las galletas salgan mal.
QC sería el inspector al final de la cadena de producción que coge una muestra de galletas, las analiza y comprueba que tienen el tamaño, el sabor y la textura correctos. Su trabajo es detectar si algo ha salido mal.
Ambos son necesarios. Pero son cosas distintas.
Cómo se aplica en el desarrollo de software
En un proyecto de software real, la diferencia se ve así:
QA incluye actividades como:
- Definir el proceso de testing antes de que empiece el desarrollo
- Revisar los requisitos para detectar ambigüedades antes de que se conviertan en bugs
- Establecer los criterios de aceptación de cada historia de usuario
- Crear el plan de pruebas
- Definir qué se automatiza y qué se testea manualmente
- Participar en las ceremonias de Scrum para garantizar la calidad desde el principio
QC incluye actividades como:
- Ejecutar los casos de prueba sobre el producto ya desarrollado
- Reportar bugs encontrados durante el testing
- Verificar que los bugs corregidos realmente están solucionados
- Ejecutar las pruebas de regresión antes de cada release
- Validar que el producto cumple los criterios de aceptación definidos
La tabla que lo deja claro
| QA | QC | |
|---|---|---|
| Qué significa | Quality Assurance | Quality Control |
| Enfoque | Preventivo | Reactivo |
| Cuándo actúa | Durante todo el proceso | Al final o en fases concretas |
| Objetivo | Evitar defectos | Encontrar defectos |
| Ejemplos | Plan de pruebas, criterios de aceptación, revisión de requisitos | Ejecución de tests, reporte de bugs, verificación de correcciones |
| Orientado a | El proceso | El producto |
Entonces, ¿qué hace exactamente un QA Engineer?
Aquí viene la confusión más habitual: en el sector tecnológico, cuando una empresa busca un «QA Engineer» o un «QA Tester», en realidad está buscando a alguien que haga las dos cosas.
El título «QA» se ha convertido en el término genérico para referirse a todo el área de calidad de software, aunque técnicamente incluya tanto actividades de QA puro como de QC.
En la práctica, un QA Engineer junior suele dedicar más tiempo a actividades de QC — ejecutar tests, reportar bugs, verificar correcciones. A medida que sube de nivel, empieza a participar más en actividades de QA — definir estrategias, revisar requisitos, establecer procesos.
¿Y el testing dónde encaja?
El testing es una actividad específica dentro del QC. Es la ejecución de pruebas para encontrar defectos en el software.
Resumiendo la jerarquía completa:
QA → engloba todo el proceso de aseguramiento de calidad QC → es una parte del QA, centrada en verificar el producto Testing → es una actividad dentro del QC, centrada en ejecutar pruebas
Por qué importa entender la diferencia
Más allá de las entrevistas, entender la diferencia entre QA y QC cambia la forma en que te planteas el trabajo.
Un QA que solo piensa en QC — es decir, que solo busca bugs al final — llega tarde. Los bugs que se detectan en fases tempranas cuestan mucho menos de corregir que los que se detectan en producción.
Un QA que también piensa en QA puro — que participa desde los requisitos, que cuestiona ambigüedades, que define procesos — aporta mucho más valor al equipo y al producto.
Es exactamente lo que describe el concepto de shift-left testing, que puedes leer en más detalle en qué es el testing shift-left y por qué importa.
Si quieres saber más sobre cómo trabaja un QA Engineer en un equipo real, puedes leer cómo funciona el QA en Scrum o ver mis servicios en fatimaqa.com.