QA, QC y Tester: por que no son sinonimos (y por que confundirlos sale caro)

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ón

La 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 proceso

QA 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.


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 producto

QC 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).


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 proceso

Y 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 restaurante

Esta 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 vida

El 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.


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ódigo

Hasta 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 realmente

Un 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.

---

Cierre

Resumiendo: 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 — You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login y You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login (CC BY-SA / GFDL).

Saludos,
ANTRAX