QA, QC y Tester: por qué no son sinónimos (y por qué confundirlos sale caro)Buenas gente de Underc0de. Hay una pregunta que aparece una y otra vez en esta sección, en entrevistas de trabajo y en discusiones de equipo:
¿cuál es la diferencia entre QA, QC y Tester? La mayoría de las respuestas que circulan son del estilo "es lo mismo, depende de la empresa". Y no, no es lo mismo. Son tres cosas de naturaleza distinta: una es un
proceso, otra es una
actividad, y la tercera es un
rol. Meterlas en la misma bolsa no es un problema de vocabulario: es lo que hace que equipos enteros terminen midiendo mal, contratando mal y arreglando bugs en el peor momento posible.
En este post voy a separar los tres conceptos, mostrar de dónde vienen, dónde encaja cada uno en el ciclo de vida del software, y qué significan en la práctica con ejemplos de código. Al final dejo una tabla comparativa y algunos mitos que conviene desarmar.
1. El origen de la confusiónLa confusión tiene una explicación histórica concreta. Los términos
Quality Assurance y
Quality Control no nacieron en el software: vienen de la industria manufacturera de mediados del siglo XX, del mundo de Deming, Juran e Ishikawa. Cuando la industria del software empezó a profesionalizarse en los 80 y 90, tomó prestado el vocabulario de las fábricas sin adaptarlo del todo.
A eso se le sumó un fenómeno muy argentino —y muy global también—: el mercado laboral usa "QA" como título genérico para cualquiera que se dedique a probar software. Vas a ver avisos que dicen "Se busca QA Manual Semi Senior" cuando en realidad lo que buscan es un tester. El título del puesto dice una cosa, las tareas dicen otra.
La norma
ISO 9000 define ambos términos de forma bastante clara:
CitarAseguramiento de la calidad (QA): parte de la gestión de la calidad orientada a proporcionar confianza en que se cumplirán los requisitos de la calidad.
Control de la calidad (QC): parte de la gestión de la calidad orientada al cumplimiento de los requisitos de la calidad.
Leelo dos veces, porque toda la diferencia está ahí. QA genera
confianza en el proceso. QC
verifica el resultado. Uno mira el cómo, el otro mira el qué.
2. QA — Quality Assurance: el procesoQA es
preventivo y está orientado al
proceso. Su pregunta de fondo no es "¿este build tiene bugs?" sino "
¿por qué nuestro proceso permite que este tipo de bug llegue hasta acá?".
Un QA de verdad no se sienta a ejecutar casos de prueba todo el día. Se dedica a cosas como:
- Definir el Definition of Done y los criterios de aceptación junto con Producto y Desarrollo.
- Establecer estándares de código, convenciones de branching y políticas de revisión.
- Diseñar la estrategia de testing: qué se automatiza, qué se prueba a mano, qué se cubre en cada nivel.
- Definir métricas y hacer que signifiquen algo (escape rate, lead time, densidad de defectos por módulo).
- Correr análisis de causa raíz cuando algo se rompe en producción.
- Meter calidad en etapas tempranas: revisión de requisitos, refinamiento, diseño.
- Auditar que el proceso definido se esté cumpliendo de verdad y no solo en la documentación.
La herramienta conceptual clásica de QA es el
ciclo PDCA (Plan-Do-Check-Act), también conocido como ciclo de Deming. Es la lógica de mejora continua: planificás un cambio, lo implementás, medís el resultado y ajustás.
(https://upload.wikimedia.org/wikipedia/commons/thumb/a/a8/PDCA_Process.png/960px-PDCA_Process.png)
Un ejemplo concreto de mentalidad QA. Supongamos que en los últimos tres sprints se escaparon a producción cinco bugs de validación de formularios. La reacción QC sería: "agreguemos más casos de prueba para formularios". La reacción QA es distinta:
Citar¿Por qué se escapan? Porque los criterios de aceptación de las historias no especifican el comportamiento ante entradas inválidas. ¿Por qué no lo especifican? Porque no tenemos una plantilla de historia que lo exija. Acción: incorporamos validaciones obligatorias al template de historia y agregamos un checkpoint en el refinamiento.
La primera respuesta agrega trabajo para siempre. La segunda
elimina la clase entera de problema. Esa es la diferencia.
3. QC — Quality Control: el productoQC es
detectivo (en el sentido de "detecta", no de Sherlock) y está orientado al
producto. Trabaja sobre algo que ya existe: un build, una release candidate, un endpoint desplegado. Su pregunta es "¿esto cumple con lo que se especificó?".
Actividades típicas de QC:
- Ejecutar casos de prueba, manuales o automatizados.
- Testing funcional, de regresión, de integración, de performance, de seguridad.
- Reportar y hacer seguimiento de defectos.
- Verificar que los criterios de aceptación se cumplan.
- Smoke testing post-deploy.
- Validar fixes y re-testear.
Acá es donde vive la famosa
pirámide de testing: la idea de que deberías tener muchas pruebas unitarias (rápidas y baratas), una cantidad moderada de pruebas de integración, y pocas pruebas end-to-end (lentas y frágiles).
(https://upload.wikimedia.org/wikipedia/commons/thumb/6/64/Testing_Pyramid.svg/960px-Testing_Pyramid.svg.png)
Ojo con un matiz importante: la pirámide es una herramienta de
QC en su ejecución, pero
decidir la forma de esa pirámide para tu proyecto es una decisión de
QA. Alguien tiene que definir la estrategia; otro alguien la ejecuta. A veces son la misma persona con dos sombreros distintos, y ahí es donde se mezcla todo.
4. Tester: el rol, no el procesoY acá viene la parte que más se malinterpreta.
Tester no es un tercer proceso. QA y QC son procesos o conjuntos de actividades. Tester es una
persona, un rol dentro del equipo.
Dicho de otra forma: un tester es quien
ejecuta principalmente actividades de QC. Es el rol humano que se sienta a diseñar casos de prueba, ejecutarlos, encontrar defectos y reportarlos.
Comparar "QA vs QC vs Tester" es técnicamente una comparación mal formada, como preguntar "¿cuál es la diferencia entre cocina, cocinar y cocinero?". Pero la pregunta se hace igual porque en el mercado los tres términos se usan como si fueran títulos de puesto intercambiables. Así que vale la pena responderla en sus propios términos.
Un buen tester, además, hace algo que ninguna automatización reemplaza:
testing exploratorio. Es decir, usar criterio, intuición y conocimiento del dominio para encontrar problemas que nadie especificó. Un script automatizado sólo encuentra lo que le dijiste que busque. Un tester con experiencia encuentra lo que a nadie se le ocurrió preguntar.
5. La analogía del restauranteEsta es la forma más rápida que conozco de explicarlo en una entrevista:
- QA es diseñar la cocina: definir las recetas estandarizadas, las temperaturas de conservación, los controles de proveedores, la capacitación del personal y los protocolos de higiene. Todo eso existe antes de que se cocine el primer plato, y su objetivo es que sea difícil cocinar mal.
- QC es probar el plato antes de que salga del pase. ¿Está a la temperatura correcta? ¿Tiene los ingredientes que dice el menú? ¿La presentación es la esperada?
- El tester es la persona que prueba el plato.
Si tu único mecanismo de calidad es probar los platos al final, vas a devolver muchos platos a la cocina. Vas a tener un
proceso de mala calidad con un
control muy activo. Funciona, pero es carísimo, lento y agota a la gente. Ese es exactamente el estado de muchos equipos de software que dicen "tenemos QA" cuando lo que tienen es QC sobrecargado.
6. Dónde encaja cada uno en el ciclo de vidaEl modelo en V muestra bien esta relación. La rama izquierda baja por las fases de definición y diseño; la derecha sube por las fases de verificación. Cada nivel de la izquierda tiene su contraparte de prueba a la derecha.
(https://upload.wikimedia.org/wikipedia/commons/thumb/f/f9/V-model.svg/960px-V-model.svg.png)
Leído en clave QA/QC:
- Toda la rama izquierda (requisitos, arquitectura, diseño) es territorio de QA. Acá se previene. Un requisito ambiguo detectado en esta etapa cuesta una fracción de lo que cuesta el bug que genera.
- Toda la rama derecha (unitarias, integración, sistema, aceptación) es territorio de QC. Acá se detecta.
- Las líneas horizontales que conectan ambas ramas son la clave: cada actividad de verificación existe porque hay algo definido del otro lado que verificar. Si no definiste bien a la izquierda, no podés verificar bien a la derecha.
Esto conecta con un principio que todo el mundo cita y poca gente aplica: el costo de corregir un defecto crece de forma no lineal según la etapa en que se detecta. Un malentendido de requisitos corregido en refinamiento cuesta una charla de diez minutos. El mismo malentendido detectado en producción cuesta un hotfix, una comunicación a clientes, posible pérdida de datos y horas de varias personas.
7. Cómo se ve en el códigoHasta acá suena abstracto, así que bajémoslo a archivos concretos. Veamos el mismo requisito atravesando los tres niveles.
QA define el criterio de aceptación (antes de que exista una línea de código). Esto es un artefacto de proceso, no una prueba:
Feature: Validacion de contrasena en el registro
# Criterio acordado en refinamiento entre Producto, Dev y QA.
# Define QUE significa "correcto". No ejecuta nada todavia.
Scenario Outline: Se rechazan contrasenas debiles
Given un usuario en el formulario de registro
When ingresa la contrasena "<password>"
Then el sistema muestra el error "<mensaje>"
And el boton de registro permanece deshabilitado
Examples:
| password | mensaje |
| abc | Minimo 8 caracteres |
| abcdefgh | Debe incluir al menos un numero |
| abcdefg1 | Debe incluir al menos una mayuscula |
| 12345678 | Debe incluir al menos una letra |
QC ejecuta la verificación. Acá ya hay código corriendo contra un producto que existe:
import pytest
from app.validators import validar_password, PasswordError
@pytest.mark.parametrize("password,mensaje_esperado", [
("abc", "Minimo 8 caracteres"),
("abcdefgh", "Debe incluir al menos un numero"),
("abcdefg1", "Debe incluir al menos una mayuscula"),
("12345678", "Debe incluir al menos una letra"),
])
def test_passwords_debiles_son_rechazadas(password, mensaje_esperado):
"""Verifica el producto contra el criterio definido por QA."""
with pytest.raises(PasswordError) as excinfo:
validar_password(password)
assert str(excinfo.value) == mensaje_esperado
def test_password_valida_es_aceptada():
assert validar_password("Underc0de2026") is True
QA diseña el proceso que hace obligatoria esa verificación. Este pipeline no prueba el producto: prueba que el equipo no pueda saltearse los controles. Es prevención pura:
name: quality-gate
on:
pull_request:
branches: [main]
jobs:
gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Linter (estandar de codigo definido por QA)
run: ruff check .
- name: Tests unitarios con umbral de cobertura
run: pytest --cov=app --cov-fail-under=80
- name: Analisis estatico de seguridad
run: bandit -r app/ -ll
# La politica: sin estos checks en verde, el merge no ocurre.
# Eso es aseguramiento, no control.
Notá la diferencia de naturaleza. El archivo de pytest responde "¿funciona?". El archivo de CI responde "¿podemos garantizar que nadie mergee sin que alguien haya preguntado si funciona?". Son preguntas de niveles distintos.
Y una métrica que un QA debería mirar, que no sale de ejecutar pruebas sino de analizar el historial:
-- Escape rate: defectos encontrados en produccion
-- sobre el total de defectos del periodo.
-- Si sube, el problema esta en el proceso, no en el ultimo build.
SELECT
DATE_TRUNC('month', fecha_reporte) AS mes,
COUNT(*) FILTER (WHERE entorno = 'produccion') AS escapados,
COUNT(*) AS total,
ROUND(
100.0 * COUNT(*) FILTER (WHERE entorno = 'produccion')
/ NULLIF(COUNT(*), 0)
, 2) AS escape_rate_pct
FROM defectos
WHERE fecha_reporte >= NOW() - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;
8. Tabla comparativa| Aspecto | QA | QC | Tester |
| Qué es | Proceso | Actividad / conjunto de técnicas | Rol / persona |
| Enfoque | Proceso | Producto | Producto |
| Naturaleza | Preventiva | Detectiva | Detectiva |
| Pregunta clave | ¿Estamos construyendo bien? | ¿Lo construido cumple? | ¿Dónde falla esto? |
| Momento | Durante todo el ciclo, sobre todo al inicio | Después de construir | Después de construir |
| Responsable | Todo el equipo | Equipo de testing | La persona en el rol |
| Ejemplo | Definir el Definition of Done | Ejecutar regresión | Diseñar y correr casos, explorar |
| Salida típica | Estándares, políticas, métricas | Reportes de defectos | Bugs, evidencia, feedback |
Regla mnemotécnica:
QA = proceso, QC = producto, Tester = persona.
9. Mitos que conviene desarmar"QA es el que rompe el software." No. Nadie rompe nada: el defecto ya estaba ahí. QC lo encuentra. Y QA idealmente hace que no llegue a existir.
"Si automatizamos todo, no necesitamos testers." La automatización es QC ejecutado por una máquina. Cubre regresión, que es repetitiva y aburrida, y lo hace excelente. Pero no hace testing exploratorio, no cuestiona requisitos y no tiene criterio sobre el negocio. Automatizás lo conocido; el tester busca lo desconocido.
"QA es responsabilidad del equipo de QA." Este es el más caro de todos. Si la calidad es "de QA", el resto del equipo delega y el área se convierte en un cuello de botella al final del sprint. QA como proceso es responsabilidad de todos: el dev que escribe unitarias está haciendo QC, y el que participa en definir el DoD está haciendo QA.
"Somos ágiles, no necesitamos procesos." Ágil no significa ausencia de proceso, significa proceso liviano y adaptable. El Definition of Done es un artefacto de QA. La retrospectiva es literalmente el "Act" del ciclo PDCA.
"QA es el escalón para pasar a desarrollo." Es una carrera con su propia progresión: tester, analista de QA, automatizador, SDET, QA lead, arquitecto de calidad. Tratarlo como sala de espera es la mejor forma de que la gente buena se vaya.
10. Cómo saber qué estás haciendo realmenteUn ejercicio honesto. Mirá tu última semana de trabajo y clasificá en qué se fue el tiempo:
- Ejecutar casos, reportar bugs, re-testear fixes → estás haciendo QC.
- Discutir criterios de aceptación, mejorar el pipeline, analizar por qué se escapó un bug, definir estándares → estás haciendo QA.
Si el 95% cae en la primera lista pero tu título dice "QA Engineer", no está mal necesariamente —es la realidad de buena parte de la industria— pero vale saberlo. Y si querés moverte hacia QA real, el camino no es aprender otra herramienta de automatización: es empezar a meterte antes en el ciclo. Pedí participar en los refinamientos. Cuestioná un requisito ambiguo
antes de que se desarrolle. La próxima vez que se escape un bug, en vez de solo agregar un caso de prueba, preguntá por qué se escapó y proponé un cambio de proceso.
CierreResumiendo:
QA es un proceso preventivo orientado a cómo se construye.
QC es un conjunto de actividades detectivas orientadas a lo construido.
Tester es el rol que ejecuta principalmente QC. No compiten entre sí y no son intercambiables: se necesitan mutuamente. QC sin QA es apagar incendios para siempre. QA sin QC es confiar en el proceso sin verificar nada.
Y un equipo maduro no elige entre uno y otro: usa QC para medir si su QA está funcionando. Si el escape rate baja sprint a sprint, tu proceso está mejorando. Si sube, no importa cuántos casos de prueba agregues, el problema está más arriba.
Abro el debate, que acá hay gente con experiencia real en el tema:
- ¿En sus empresas el rol de QA hace QA de verdad o es QC con otro nombre?
- ¿Les tocó implementar algún cambio de proceso que haya bajado defectos de forma medible?
- ¿Cómo manejan la tensión entre presión de entrega y calidad?
Nos leemos.
Créditos de las imágenes: diagramas de Wikimedia Commons — PDCA Process (https://commons.wikimedia.org/wiki/File:PDCA_Process.png), Testing Pyramid (https://commons.wikimedia.org/wiki/File:Testing_Pyramid.svg) y V-model (https://commons.wikimedia.org/wiki/File:V-model.svg) (CC BY-SA / GFDL).Saludos,
ANTRAX