QA vs testing vs control de calidad: no son lo mismo

Un equipo dice "tenemos QA" y casi siempre quiere decir "tenemos a alguien que prueba la app antes de sacarla". Eso no es QA. Eso es testing, y ni siquiera todo el testing. La confusión suena inofensiva hasta que llega la factura: contratas a un tester creyendo que compraste un proceso de calidad, mides defectos encontrados creyendo que mides calidad, y te sorprende que los mismos errores vuelvan release tras release.

QA, testing y control de calidad son tres cosas distintas que trabajan juntas. Una previene, otra verifica, otra inspecciona. Separarlas no es purismo de manual: es lo que te dice a quién contratar, qué medir y en qué momento del proyecto actuar. Aquí las desarmo una por una y te dejo la tabla que puedes pegar en la pared del equipo.

01 · el procesoQA es prevención: se ocupa de cómo se construye

Aseguramiento de calidad (Quality Assurance) es un enfoque de proceso. No mira el producto terminado: mira la forma en que se produce. Su pregunta no es "¿está bien esta versión?", sino "¿estamos trabajando de una manera que evite que salgan defectos?". Por eso es preventivo y por eso ocurre a lo largo de todo el ciclo, no al final.

QA define estándares, define cómo se revisa el código, cómo se documentan los requisitos, qué criterios debe cumplir una historia para considerarse lista. Cuando QA funciona, muchos defectos ni siquiera llegan a existir porque el proceso los cerró antes. El ISTQB lo resume claro: el aseguramiento de calidad se centra en el cumplimiento de procesos adecuados para dar confianza en que se alcanzará la calidad esperada [1].

QA no revisa el pastel. Revisa la receta, el horno y la mano de quien cocina.

Esto tiene una consecuencia incómoda para quien contrata: no puedes "poner QA" al final de un proyecto y esperar milagros. Si el proceso fue caótico durante seis meses, meter una persona la última semana no asegura calidad, solo la mide. QA es una decisión que se toma al principio y se sostiene todo el camino.

02 · la actividadTesting es verificación: ejecuta el producto para hallar fallas

Las pruebas (testing) son una actividad concreta: ejecutar el software con la intención de encontrar defectos y de comprobar que hace lo que debe. Es dinámica por naturaleza: corre el sistema, le mete entradas, observa salidas y las compara con lo esperado. Testing es una de las herramientas del control de calidad, no un sinónimo de calidad en sí.

Aquí conviene recordar un principio viejo y todavía ignorado: las pruebas demuestran la presencia de defectos, nunca su ausencia. Encontrar cero errores no significa que el software esté perfecto; puede significar que probaste poco o probaste mal [1]. Por eso "cuántos casos de prueba pasaron" es una métrica que engaña si se lee sola.

Testing tampoco es una sola cosa. Hay pruebas que verifican el código por dentro (unitarias, de integración) y pruebas que validan el comportamiento visible (de sistema, de aceptación). Un tester ejecuta y reporta; un buen tester diseña qué probar para que cada prueba cuente. Pero incluso el mejor testing sigue siendo verificación al final de la cadena, no prevención en el origen.

03 · la inspecciónControl de calidad es detección: inspecciona lo ya construido

El control de calidad (Quality Control) es detección. Es la inspección orientada al producto: toma lo que ya se construyó y verifica si cumple los criterios de calidad definidos. Mientras QA pregunta "¿el proceso es bueno?", QC pregunta "¿este resultado concreto cumple?". Es reactivo por diseño: actúa sobre algo que ya existe.

Testing es la principal actividad de QC, pero QC es más amplio: incluye revisiones de producto, inspecciones, verificación contra especificaciones y criterios de aceptación. La norma ISO/IEC 25010 aporta aquí el vocabulario que hace la inspección seria: define un modelo de calidad de producto con características medibles como funcionalidad adecuada, fiabilidad, usabilidad, seguridad y mantenibilidad [2]. Sin ese modelo, "¿cumple?" es una opinión; con él, es una medición.

04 · la tablaQuién hace qué, cuándo y con qué mentalidad

Puestos uno al lado del otro, los tres dejan de confundirse. QA es el paraguas de proceso; QC es la inspección del producto; testing es la actividad concreta que alimenta a QC. La relación no es de rivalidad sino de encaje: el testing sirve al control de calidad, y el control de calidad vive dentro del aseguramiento de calidad.

Contratas mal cuando pides QA y describes un tester. Mides mal cuando cuentas pruebas y crees que cuentas calidad.

La consecuencia práctica es doble. Primero, en contratación: si tu proceso es un desastre, no lo arregla un tester; necesitas alguien que trabaje el proceso (QA). Si tu proceso es sano pero necesitas encontrar fallas antes de entregar, necesitas quien ejecute pruebas (testing/QC). Son perfiles y momentos distintos. Segundo, en métricas: "defectos encontrados" mide actividad de QC, no calidad del proceso. Un buen indicador de QA es lo contrario: defectos que no ocurrieron porque el proceso los previno, algo que se ve en la tendencia de defectos que escapan a producción a lo largo del tiempo, no en un número de pruebas ejecutadas.

Que estos términos se usen como sinónimos en las reuniones no es grave por pedantería. Es grave porque cada uno responde a una necesidad distinta, y mezclarlos hace que gastes en lo que no era y midas lo que no importa. Sepáralos y de golpe sabes a quién llamar, en qué momento y qué número mirar.