# QA, Testing y Quality Control: diferencias y responsabilidades

**Categoría:** Testing y QA · **Nivel:** Inicial · **Lectura:** 12 min
**Publicada:** 2026-07-29 · **Actualizada:** 2026-07-29 · **Autoría:** Underc0de, con base en el aporte de GENIOL en el foro
**Versión HTML (canónica):** https://underc0de.org/guias/testing/qa-testing-y-quality-control-diferencias/

## Respuesta rápida

> **QA** (*quality assurance*, aseguramiento de la calidad), **QC** (*quality control*, control de calidad) y **testing** no son sinónimos. QA está orientado al **proceso** y es **preventivo**; QC está orientado al **producto** y es **detectivo**; y el testing es la **actividad** de ejecución que ocurre dentro de QC, no de QA. Dicho de otro modo: QA abarca el proceso completo, QC se ocupa del producto, y testing es una de las formas de hacer QC. Esta guía retoma la distinción reactivo/proactivo que desarrolló GENIOL en el foro de Underc0de, la contrasta con el glosario de ISTQB, y cierra con el punto que más importa: quién responde realmente por la calidad en un equipo, que no es únicamente el área de QA. Si venís de la [introducción al testing](../introduccion-al-testing/index.md) o de la [ruta de aprendizaje QA](../ruta-de-aprendizaje-qa-manual-y-automation/index.md), esta guía profundiza el vocabulario que ambas dan por conocido.

## Qué es QA, QC y Testing

**QA** es la sigla de *quality assurance*, aseguramiento de la calidad. El glosario del ISTQB (International Software Testing Qualifications Board, el organismo que certifica testers a nivel internacional) lo describe, en esencia, como un conjunto de actividades enfocadas en dar confianza en que se van a cumplir los requisitos de calidad. En criollo: QA mira el **proceso** de trabajo —requisitos, revisión de código, definición de «terminado»— para que los defectos no lleguen a producirse.

**QC** es la sigla de *quality control*, control de calidad. El mismo glosario lo describe, en esencia, como el conjunto de actividades enfocadas en verificar que un entregable cumple los requisitos de calidad establecidos. La diferencia con QA está en el objeto que cada uno mira: QC se enfoca en el **producto** —código, build, documentación— ya construido, para detectar ahí los defectos que ya existen.

El **testing** es la actividad concreta de ejecutar un componente o un sistema para evaluarlo, comparando su comportamiento real con el esperado. Dentro de esta jerarquía, el testing es una actividad de QC: no reemplaza a QC ni es sinónimo de QA, es una de las formas —probablemente la más conocida— de hacer control de calidad.

> **La relación en una línea**
>
> QA abarca el proceso completo; QC controla la calidad del producto dentro de ese proceso; testing es la actividad de ejecución central dentro de QC. No son tres cosas equivalentes: son tres capas de una misma jerarquía.

## La jerarquía: proceso, producto y actividad

Puesto en una tabla, cada aspecto deja más clara la diferencia entre los tres términos, y por qué usarlos como sinónimos genera malentendidos en el día a día.

| Aspecto | QA (aseguramiento) | QC (control) | Testing |
|---|---|---|---|
| Orientado a | El proceso de trabajo | El producto construido | El producto, en un caso puntual |
| Naturaleza | Preventiva | Detectiva | Detectiva |
| Pregunta que responde | ¿El proceso está diseñado para no producir defectos? | ¿Este entregable cumple los requisitos de calidad? | ¿Este caso concreto se comporta como se espera? |
| Relación entre ellos | Incluye a QC como una de sus prácticas | Incluye al testing como su actividad central | Es una actividad que ocurre dentro de QC |
| Ejemplo típico | Definir criterios de aceptación antes de programar | Revisar que un build cumple esos criterios antes de liberarlo | Ejecutar un caso de prueba y comparar el resultado |

![Diagrama de la jerarquía entre QA, QC y Testing, representada como tres recuadros anidados de afuera hacia adentro. El recuadro más externo corresponde a Quality Assurance (QA): está etiquetado como proceso y preventivo, y su descripción indica que da confianza en que el proceso de trabajo va a cumplir los requisitos de calidad, actuando desde antes de que exista código, al revisar requisitos, procesos y criterios. Dentro de él hay un recuadro más chico para Quality Control (QC): está etiquetado como producto y detectivo, y su descripción indica que detecta defectos evaluando los entregables ya construidos, como código, builds, documentación e interfaces. Dentro de QC hay un tercer recuadro, el más pequeño, para Testing: se indica que es la actividad central dentro de QC, consistente en ejecutar pruebas y comparar el resultado real con el esperado para encontrar defectos en el producto. Debajo de los recuadros anidados hay una línea de tiempo con cinco fases del ciclo de vida de un proyecto de software: requisitos, diseño, desarrollo, pruebas, y entrega y mantenimiento. Una barra azul indica que QA está presente y activo a lo largo de las cinco fases, porque su foco es preventivo y de proceso. Otra barra, de un celeste más claro, indica que QC y Testing recién se activan a partir de la fase de desarrollo y continúan durante las pruebas, la entrega y el mantenimiento, porque necesitan que exista un entregable construido para poder evaluarlo. Una nota final aclara que el testing es una actividad de ejecución dentro de QC, y que QA empieza antes de que exista código para probar.](../../assets/img/guias/qa-qc-testing-jerarquia.svg)

*QA abarca todo el ciclo de vida y actúa de forma preventiva sobre el proceso; QC y testing entran en escena recién cuando existe un entregable para evaluar, y actúan de forma detectiva sobre el producto.*

Si querés bajar esta jerarquía a qué probar primero y con qué profundidad, eso lo desarrolla la guía de [estrategias de prueba](../estrategias-de-prueba/index.md).

## Reactivo y proactivo: el aporte de la comunidad

En el foro de Underc0de, **GENIOL** publicó en junio de 2021, en la sección QA (Quality Assurance), un análisis que resume esta distinción desde la experiencia práctica y no desde una norma: *«El abismo entre tester y QA»* plantea que el tester actúa de forma **reactiva** —ejecuta las pruebas ya diseñadas y reporta los defectos que encuentra— mientras que el QA actúa de forma **proactiva**, interviniendo en todo el ciclo de vida para que esos defectos no lleguen a producirse. Es una lectura razonada de la comunidad que aterriza en términos concretos lo que el glosario de ISTQB describe de forma más abstracta, no una clasificación normativa en sí misma.

- **Actividades reactivas, más asociadas al tester:** ejecutar casos de prueba ya diseñados, registrar con precisión los defectos encontrados durante la ejecución, y verificar que una corrección puntual resolvió el problema reportado.
- **Actividades proactivas, más asociadas al QA:** revisar requisitos antes de que se programen, participar en la definición de criterios de aceptación, proponer mejoras al proceso de desarrollo, y hacer seguimiento de métricas de calidad a lo largo de todo el proyecto.

Esas actividades reactivas son las que desarrolla en detalle la guía de [testing manual desde cero](../testing-manual-desde-cero/index.md). En equipos chicos una misma persona suele hacer ambas cosas según el momento, y el nombre del puesto no siempre refleja qué función está cumpliendo.

Que la duda sea real lo confirma otra pregunta del propio foro: en 2022, **FedeGrammer** preguntó abiertamente cuál es la diferencia entre QC y QA, sin respuesta cerrada. En una línea similar, **ANTRAX** planteó que el QA mide la calidad no solo del producto sino también del proceso de desarrollo.

## En qué momento del ciclo actúa cada uno

Esa naturaleza preventiva de QA y detectiva de QC explica cuándo entra en escena cada disciplina a lo largo de un proyecto.

1. **Requisitos.** QA ya está presente: revisa que los requisitos estén completos y sean verificables. Todavía no hay ningún entregable, así que QC y testing no tienen nada que evaluar.
2. **Diseño.** QA sigue actuando sobre el proceso, participando en la definición de criterios de aceptación y de arquitectura. QC y testing siguen sin tener nada concreto sobre qué trabajar.
3. **Desarrollo.** Aparece el primer entregable evaluable —código, un build parcial— y ahí arranca QC. El testing, como actividad central de QC, puede empezar apenas hay algo ejecutable.
4. **Pruebas.** Es el momento de mayor actividad de QC y testing: se ejecutan los casos diseñados, se reportan los defectos y se verifica que las correcciones funcionen. QA sigue en paralelo, revisando si el proceso que llevó hasta acá puede mejorarse.
5. **Entrega y mantenimiento.** QC vuelve a intervenir cada vez que hay un cambio para evaluar. QA cierra el ciclo analizando qué del proceso funcionó y qué no, de cara a la próxima iteración.

Documentar con qué cobertura y con qué criterios de entrada y salida se va a llegar a la etapa de pruebas es, justamente, el objetivo de un [plan de pruebas completo](../como-crear-un-plan-de-pruebas-completo/index.md).

## ¿Un QA puede hacer QC, y viceversa?

Sí, y en la mayoría de los equipos reales es lo habitual. QA y QC no son necesariamente dos puestos distintos: son dos **funciones**, y la misma persona suele ejercerlas ambas según el momento. Es un error frecuente pensar que «QC» es un cargo del organigrama: quien ejecuta control de calidad —incluido el testing— se llama analista de QA, tester o ingeniero de calidad, y en el mismo día puede pasar de revisar un requisito antes de programar (función de QA) a ejecutar una prueba sobre un build ya construido (función de QC).

La pregunta útil no es «¿esta persona es QA o es QC?», sino «¿qué está haciendo en esta tarea?». Si actúa sobre el proceso antes de que exista algo para evaluar, hace QA. Si evalúa algo que ya existe para encontrar defectos, hace QC.

## La calidad no es solo responsabilidad de QA

El propio hilo de GENIOL en el foro de Underc0de lo dice de forma explícita, y es el punto más importante de toda esta distinción: **la calidad no es responsabilidad exclusiva del equipo de QA**. Un QA proactivo puede revisar requisitos y acompañar todo el ciclo de vida, pero si quien programa no valida sus propios cambios, si el equipo no discute criterios de aceptación antes de construir, o si nadie prioriza corregir lo que el testing encontró, ningún rol de QA alcanza para sostener la calidad de un producto.

QA y QC dan estructura, método y visibilidad a un trabajo que, en última instancia, es de todo el equipo: quien escribe el código, quien define el producto y quien decide qué se libera. Tratar la calidad como «el problema de QA» es, de hecho, uno de los motivos por los que muchos equipos siguen liberando defectos evitables.

## Errores frecuentes

- **Usar QA y testing como sinónimos.** Testing es una actividad puntual dentro de QC; QA es un enfoque de proceso mucho más amplio.
- **Creer que QC es un puesto de trabajo.** Es una función que puede ejercer la misma persona que hace QA, según el momento.
- **Pensar que solo QA responde por la calidad.** El propio hilo de GENIOL lo contradice: la calidad depende de todo el equipo.
- **Reducir el rol de QA a «buscar bugs».** Menosprecia la parte proactiva, la más difícil de reemplazar.
- **Aplicar solo el enfoque reactivo.** Probar mucho sin prevenir nada deja pasar los mismos tipos de defecto una y otra vez.

## Preguntas frecuentes

**¿Cuál es la diferencia entre QA, QC y Testing?**
QA (quality assurance, aseguramiento de la calidad) es un enfoque orientado al proceso: previene defectos actuando sobre cómo se trabaja, y por eso es preventivo. QC (quality control, control de calidad) está orientado al producto: evalúa los entregables ya construidos —código, builds, documentación— para detectar los defectos que ya existen en ellos, y por eso es detectivo. El testing es la actividad concreta que ocurre dentro de QC: ejecutar un componente o sistema y comparar su comportamiento real con el esperado. No son sinónimos sino capas: QA abarca el proceso completo, QC es una de sus prácticas sobre el producto, y testing es la actividad de ejecución más conocida dentro de QC. Confundirlos lleva a esperar que un QA solo ejecute pruebas, o a creer que testear mucho equivale a tener un proceso de calidad.

**¿Un QA puede hacer QC y viceversa?**
Sí, y en la mayoría de los equipos reales es lo habitual. QA y QC no son necesariamente dos puestos distintos: son dos funciones, y la misma persona suele ejercerlas según el momento. Es un error pensar que «QC» es un cargo del organigrama: quien ejerce control de calidad —incluido el testing— suele llamarse analista de QA, tester o ingeniero de calidad, y en el mismo día puede pasar de revisar un requisito antes de programar (función de QA) a ejecutar una prueba sobre un build ya construido (función de QC). Lo que cambia no es la persona ni el título, sino qué está haciendo en esa tarea.

**¿Tester y QA son el mismo puesto?**
No necesariamente, aunque en equipos chicos suelen ser la misma persona con dos funciones distintas. La distinción de GENIOL en el foro de Underc0de ayuda acá: el tester tiende a actuar de forma reactiva, ejecutando casos ya diseñados y reportando defectos sobre lo que ya existe; el QA tiende a actuar de forma proactiva, revisando requisitos y criterios de aceptación antes de que haya algo que probar. En organizaciones grandes esto puede reflejarse en puestos separados, pero en la mayoría de los proyectos una misma persona combina ambas funciones. Conviene mirar qué actividades hace esa persona, más que el nombre de su puesto.

**¿Quién es responsable de la calidad en un equipo ágil?**
Todo el equipo, no solo quien ocupa un rol de QA. Lo plantea con claridad el propio hilo de GENIOL en el foro de Underc0de: un QA proactivo puede revisar requisitos y acompañar todo el ciclo, pero eso no alcanza si quien programa no valida sus propios cambios, si el equipo no discute criterios de aceptación antes de construir, o si nadie prioriza corregir lo que el testing encontró. En un equipo ágil la calidad se construye en cada rol: quien escribe código, quien define el producto y quien decide qué se libera. QA y QC dan método y visibilidad a ese trabajo compartido, pero no reemplazan la responsabilidad de cada rol.

**¿En qué momento del ciclo de vida entra cada disciplina?**
QA está presente desde el principio, incluso antes de que exista código: revisa requisitos, participa en los criterios de aceptación y de arquitectura, y sigue actuando durante todo el proyecto. QC necesita que exista algo construido para evaluarlo, así que entra recién con el primer entregable y se mantiene activo durante el desarrollo, las pruebas, la entrega y el mantenimiento. El testing, como actividad central de QC, sigue el mismo ritmo: arranca apenas hay algo ejecutable y se concentra en la etapa de pruebas. En la práctica, QA cubre las cinco fases típicas de un proyecto, mientras que QC y testing solo cubren las últimas tres.

**¿Qué actividades hace un QA que no hace un Tester?**
Un QA proactivo hace cosas que no requieren ejecutar ninguna prueba: revisar un requisito antes de que se programe, participar en la definición de criterios de aceptación, proponer cambios al proceso cuando un mismo tipo de defecto se repite, y hacer seguimiento de métricas de calidad a lo largo de todo el proyecto. Un tester, en su función más reactiva, se concentra en ejecutar los casos ya diseñados, registrar con precisión los defectos que encuentra, y verificar que una corrección resolvió el problema. La diferencia no es de jerarquía: son dos formas de aportar a la calidad, una antes de que el problema exista y otra después de que el producto ya se construyó.

## Fuentes

Documentación oficial y aportes de la comunidad consultados para esta guía. Fecha de consulta: 29 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [El abismo entre tester y QA](https://underc0de.org/foro/qa-(quality-assurance)/el-abismo-entre-tester-y-qa/), por *GENIOL*, sección QA (Quality Assurance), 15/06/2021. Columna vertebral: tester reactivo vs. QA proactivo.
2. **Underc0de, foro.** [¿Por qué es fundamental el QA en un proyecto?](https://underc0de.org/foro/qa-testing/por-que-es-fundamental-el-qa-en-un-proyecto/), por *ANTRAX*, sección QA (Quality Assurance), 09/02/2020. El QA mide la calidad del proceso, no solo del producto.
3. **Underc0de, blog.** [¿Por qué es fundamental el QA en un proyecto?](https://blog.underc0de.org/por-que-es-fundamental-el-qa-en-un-proyecto/), por *ANTRAX*. Versión en el blog del mismo planteo.
4. **Underc0de, foro.** [¿Cuál es la diferencia entre QC y QA?](https://underc0de.org/foro/dudas-generales-121/cual-es-la-diferencia-entre-qc-y-qa/), por *FedeGrammer*, sección Dudas y pedidos generales, 03/06/2022. Muestra que la duda es real y recurrente.

### Documentación oficial

5. **ISTQB.** [Glosario: quality assurance](https://glossary.istqb.org/en_US/term/quality-assurance). Definición de QA, parafraseada.
6. **ISTQB.** [Glosario: quality control](https://glossary.istqb.org/en_US/term/quality-control). Definición de QC, parafraseada.
7. **ISTQB.** [Certified Tester Foundation Level](https://www.istqb.org/certifications/certified-tester-foundation-level). Certificación que estandariza el vocabulario.

## Guías relacionadas

- [Introducción al testing](../introduccion-al-testing/index.md)
- [Testing manual desde cero](../testing-manual-desde-cero/index.md)
- [Estrategias de prueba](../estrategias-de-prueba/index.md)
- [Cómo crear un plan de pruebas completo](../como-crear-un-plan-de-pruebas-completo/index.md)
- [Ruta de aprendizaje QA manual y automation](../ruta-de-aprendizaje-qa-manual-y-automation/index.md)

URL canónica: https://underc0de.org/guias/testing/qa-testing-y-quality-control-diferencias/