Quien busca pruebas de calidad de software suele preguntar por tres trabajos distintos a la vez. El aseguramiento de la calidad (QA) da forma al proceso para que se cometan menos errores, el control de calidad (QC) revisa el producto que tu equipo ha construido en busca de problemas, y el testing es el trabajo práctico que aporta la mayor parte de la evidencia del QC.
Confundir estos tres trabajos sale caro a la hora de formar un equipo para un proyecto. Una empresa con un proceso débil puede contratar a alguien que solo ejecuta casos de prueba, mientras que una startup con pocos testers puede pagar a un consultor para que rediseñe su flujo de trabajo. En ambos casos, el presupuesto se va en el tipo de ayuda equivocado.
Esta guía explica QA, QC y testing con palabras sencillas, a partir de las definiciones oficiales del ISTQB, el organismo que certifica a testers de software a nivel internacional. También verás cómo encajan estos trabajos en un proyecto real y qué preguntar antes de contratar. Si prefieres confiar los tres a un solo socio, nuestro equipo de QA dedicado trabaja así.
¿Por qué las pruebas de calidad de software son en realidad tres trabajos distintos?
Cada uno de los tres trabajos responde a una pregunta distinta. El QA se pregunta si el equipo trabaja de una forma que produce buen software, y el QC decide si esta versión concreta está lista para salir. El testing busca dónde se rompe el producto y reúne la evidencia que el QC necesita para tomar esa decisión.
El aseguramiento de la calidad previene defectos en el proceso
El glosario del ISTQB define el aseguramiento de la calidad como «actividades que se centran en proporcionar confianza en que se cumplirán los requisitos de calidad». Dicho de forma sencilla, el QA establece hábitos de trabajo que previenen los errores, que los testers llaman defectos.
En el día a día, el trabajo de QA consiste sobre todo en planificar y acordar reglas. Un especialista en QA revisa la descripción escrita de cada funcionalidad y se asegura de que sea lo bastante clara para desarrollarla y probarla. Parte del trabajo es acordar qué significa «terminado», qué se prueba antes de cada lanzamiento y cómo se notifican y se siguen los problemas. Cuando aun así un error llega a los usuarios, el QA busca el hueco en el proceso que lo dejó pasar.
El control de calidad encuentra defectos en el producto
El control de calidad es la parte de comprobación. El glosario del ISTQB describe el QC como «actividades diseñadas para evaluar la calidad de un componente o sistema». En pocas palabras, el QC compara lo que tu equipo ha construido realmente con lo que planeaste construir.
El QC entra en juego cuando ya hay algo que inspeccionar, como una sola pantalla, una funcionalidad nueva o una versión completa. Los testers dividen este trabajo en dos partes, conocidas como verificación y validación:
- Verificación: ¿El producto se ajusta al plan escrito?
- Validación: ¿Los usuarios reales obtienen del producto lo que necesitan?
El testing es la principal forma de hacer control de calidad
El testing consiste en usar el software de forma deliberada para encontrar problemas antes que tus clientes. El programa de estudios del ISTQB dice que el testing y el QA «no son lo mismo» y llama al testing «una forma principal de control de calidad». Es decir, el testing es una parte del QC, y el QC trabaja junto al QA.
Las pruebas manuales consisten en que una persona recorra la aplicación como lo haría un cliente. Este enfoque práctico detecta pantallas confusas y comportamientos extraños que las comprobaciones automatizadas suelen pasar por alto. Las pruebas automatizadas usan pequeños programas para repetir los mismos pasos rápidamente en cada nueva versión. Ambos tipos dan el mismo resultado: evidencia sobre cómo funciona el producto en este momento.
QA vs QC vs testing de un vistazo
QA vs QC vs testing se resume en tres focos: el proceso, el producto y las comprobaciones prácticas entre ambos.
Pregunta principal
¿Trabajamos de una forma que produce buen software?
¿Esta versión es lo bastante buena para publicarse?
¿Dónde se rompe el software y cómo?
Foco
El proceso
El producto
Funcionalidades y flujos de usuario concretos
Objetivo
Prevenir defectos
Encontrar defectos
Encontrar y describir defectos
Momento
Antes y durante todo el desarrollo
Cuando ya hay algo que comprobar
Durante y después del desarrollo, antes de cada lanzamiento
Trabajo típico
Revisión de requisitos, planes de pruebas, criterios de lanzamiento, mejoras del proceso
Ejecución de pruebas, clasificación de errores por gravedad, decisiones de lanzamiento
Ejecutar casos de prueba, explorar la aplicación, redactar informes de errores
Responsable
Todo el equipo del proyecto, guiado por especialistas en QA
El equipo de QA o de testing
Testers e ingenieros de QA
El ISTQB añade que el QA «es responsabilidad de todos los miembros de un proyecto», así que ninguna contratación ni ningún proveedor puede encargarse de la calidad en solitario.
¿Cómo encaja el proceso de aseguramiento de la calidad del software con el testing?
En un equipo bien organizado, QA, QC y testing funcionan como un ciclo. El QA fija las reglas, el testing reúne la evidencia y el QC convierte los hallazgos en una decisión de lanzamiento. Después de cada lanzamiento, el equipo revisa qué salió mal y ajusta el plan para el siguiente ciclo. Mantener ese ciclo en marcha de un lanzamiento al siguiente es la tarea del proceso de aseguramiento de la calidad del software, y nuestra guía sobre el proceso de QA recorre cada paso.
Cómo repartimos QA, QC y testing para DrAnsay
Montamos los tres trabajos desde cero para DrAnsay, una plataforma alemana de recetas en línea con 700.000 pacientes. Al principio, DrAnsay no tenía un equipo interno de QA, y los errores recurrentes seguían llegando a los pacientes mientras pedían sus recetas.
Así se repartió el trabajo entre QA, testing y QC:
- Aseguramiento de la calidad: Empezamos explorando las aplicaciones web y móvil, y convertimos los hallazgos en un plan de pruebas. Nuestros ingenieros también revisaron los documentos de funcionalidades y los diseños antes del desarrollo, para que los huecos salieran a la luz antes de escribir código. Los casos de prueba, los planes para volver a comprobar las funcionalidades existentes y el seguimiento de errores pasaron a una sola herramienta, Qase.io, para que todos vieran la misma imagen.
- Testing: Nuestros ingenieros recorrieron a mano el flujo de pedido de recetas en web y móvil. También escribimos más de 40 pruebas automatizadas con Playwright, una herramienta de automatización de navegadores muy utilizada, para los recorridos de usuario más importantes. Esas pruebas se ejecutan a diario e informan al canal de Slack del equipo.
- Control de calidad: Los resultados indicaban al equipo de DrAnsay qué había que corregir antes de que cada nueva versión pudiera publicarse.
Reportamos más de 150 errores, y más de 60 de ellos nunca llegaron a producción. Los pedidos de DrAnsay crecieron un 15% y los pagos abandonados bajaron un 18%.
Una sola ronda de pruebas justo antes del lanzamiento encuentra los errores tarde. Por eso implicamos al QA desde las primeras descripciones de funcionalidades y seguimos comprobando a lo largo de todas las fases de las pruebas de software.
¿Qué ocurre cuando fallan el QA o el QC?
Dos grandes caídas de 2025 muestran la diferencia entre un hueco en el proceso y un defecto no detectado.
Cloudflare es un proveedor de red del que dependen muchos sitios web para su velocidad y seguridad. El 18 de noviembre de 2025, la empresa sufrió su peor caída desde 2019, según su propio informe. Un cambio en los permisos de una base de datos hizo que un archivo de configuración interno duplicara su tamaño. El programa que lo carga tenía un límite de 200 entradas y falló en cuanto la versión sobredimensionada se extendió por la red. La solución de Cloudflare es un cambio de proceso: la empresa prevé revisar los archivos que generan sus propios sistemas con el mismo rigor que los datos que introducen los usuarios. La caída es una lección de QA, porque el hueco estaba en las reglas sobre qué se inspecciona.
En octubre de 2025, un fallo grave afectó a una región de Estados Unidos de Amazon Web Services (AWS), la plataforma en la nube que hay detrás de muchas aplicaciones. AWS atribuyó la causa a lo que su informe llama una condición de carrera latente. Ese término describe un error de sincronización oculto que solo aparece cuando dos procesos automatizados actualizan los mismos registros a la vez. Entre las soluciones de AWS figura un conjunto de pruebas adicional, es decir, un nuevo grupo de comprobaciones repetibles, para uno de los sistemas de recuperación de la empresa. La caída de AWS es una lección de QC, ya que un defecto superó las salvaguardas que ya existían.
Tus propios incidentes pueden clasificarse de la misma manera. Después de cualquier error grave, pregúntate si el proceso permitió el riesgo o si las comprobaciones no detectaron el defecto. La respuesta te dice si necesitan mejoras tu QA, tu QC o ambos.
¿La ingeniería de calidad está sustituyendo al QA?
No, la ingeniería de calidad (QE) es una forma más amplia de organizar los mismos tres trabajos. El término QE aparece a menudo en ofertas de empleo y en propuestas de proveedores. El glosario del ISTQB describe la ingeniería de la calidad como prácticas en las que «los implicados comparten la responsabilidad, de forma conjunta» de la calidad. Los implicados son todas las personas con voz en el software, desde desarrolladores y testers hasta los responsables de producto.
La idea nace del principio del QA según el cual la calidad es trabajo de todo el equipo. En un modelo de QE, los desarrolladores escriben comprobaciones automatizadas para su propio código, los testers ayudan a dar forma a las funcionalidades desde el principio y los responsables de producto acuerdan qué debe superarse antes del lanzamiento. QA, QC y testing siguen existiendo dentro de la QE, así que las definiciones anteriores de esta guía siguen siendo válidas.
¿Qué contratas cuando contratas a un ingeniero de QA?
Los nombres de los puestos aumentan la confusión. Según nuestra experiencia, el típico «ingeniero de QA» dedica la mayor parte de la semana al trabajo práctico: escribir casos de prueba, ejecutar las comprobaciones y reportar errores. El trabajo de proceso ocupa el resto de las horas, y su peso suele crecer con la experiencia. Por eso, alguien contratado con este título cubre buena parte del QC, pero solo una parte del QA.
Un encargo solo de testing puede ser exactamente la elección correcta. Para Chesapeake Technology probamos SonarWiz, un software de escritorio que más de 4.000 organizaciones utilizan para cartografiar el fondo marino. El cliente ya tenía sus propios casos de prueba, así que nuestros ingenieros se centraron en ejecutarlos. SonarWiz es un producto complejo que lee más de 60 formatos de datos de sonar. Solo en la fase inicial del encargo aparecieron más de 50 errores, entre ellos un pequeño fallo de metadatos que desplazaba las coordenadas del mapa miles de kilómetros.
Los proveedores tampoco son siempre precisos con las etiquetas, y eso nos incluye a nosotros. Nuestro caso práctico describe el proyecto para Elsewhen, una consultora londinense de productos digitales, como una auditoría de QA. En la práctica, probamos un sitio web rediseñado en cuanto a funcionalidad, aspecto visual, accesibilidad, visibilidad en buscadores y velocidad. De los errores que reportamos, el 41% tenía que ver con la coherencia del diseño y el 20% afectaba a usuarios con discapacidad. Todas las comprobaciones se centraron en el propio producto, así que, según las definiciones del ISTQB, el proyecto fue QC.
Antes de contratar a una persona o a un proveedor para un trabajo de pruebas de calidad de software, haz algunas preguntas directas:
- ¿Revisaréis nuestros requisitos y nuestro proceso de lanzamiento, o solo probaréis lo que os entreguemos?
- ¿Quién escribe los casos de prueba y quién los mantiene al día?
- ¿Cómo llegan los resultados de las pruebas a nuestros desarrolladores, y quién decide si se publica una versión?
- ¿Qué cambia en nuestro proceso si el mismo tipo de error sigue apareciendo?
Las respuestas te muestran si estás comprando QA, QC, testing o una combinación de los tres.
Los términos correctos fijan las expectativas correctas
Conocer la diferencia entre QA, QC y testing te dice qué esperar de una nueva contratación, de un proveedor o de una revisión de cómo trabaja tu equipo. Cuando busques servicios de pruebas de calidad de software, fíjate en tres cosas:
- Un proceso que prevenga los defectos
- Comprobaciones que detecten los errores que se cuelan
- Revisiones periódicas que conviertan cada error no detectado en una solución duradera
En QAwerk, un solo equipo cubre tanto el proceso como el testing práctico, así que no tienes que coordinar a varios proveedores. Para saber si tu proyecto necesita más QA, más QC o más testing, habla con nuestros ingenieros de QA.
Preguntas frecuentes
¿Cuál es la diferencia entre QA, QC y testing?
En las pruebas de calidad de software, QA, QC y testing son tres trabajos conectados. Piensa en la cocina de un restaurante: el QA son las recetas y las normas de higiene que evitan que se preparen platos malos, el QC es la decisión del jefe de cocina sobre si cada plato es lo bastante bueno para servirlo, y el testing es la cata que orienta al chef. El QA previene los defectos, mientras que el QC y el testing los encuentran.
¿El testing forma parte del QA o del QC?
El testing pertenece al control de calidad. Según el ISTQB, el organismo internacional que certifica a los testers, el testing es una forma principal de QC. Examinar el propio software es exactamente aquello para lo que existe el QC. El QA trabaja un nivel por encima y decide cuándo se prueba, cuánto es suficiente y qué cambia cuando los mismos errores siguen volviendo.
¿Un ingeniero de QA hace aseguramiento de la calidad o testing?
La mayoría de los ingenieros de QA hacen ambos tipos de trabajo, en distintas proporciones. En un equipo típico, los perfiles junior e intermedios dedican la mayor parte de su tiempo al testing práctico. Los ingenieros sénior y los líderes de QA asumen más trabajo de proceso, como revisar los requisitos de las funcionalidades y fijar los criterios de lanzamiento. Los títulos varían mucho, así que lee las funciones que figuran en una oferta de empleo o en la propuesta de un proveedor para ver el reparto real.
¿Puede un solo equipo encargarse tanto del QA como del QC?
Sí, y para las empresas pequeñas y medianas, un solo equipo suele ser la opción más sencilla. Las personas que prueban cada versión también ven de dónde vienen los errores, así que pueden corregir el proceso de fondo sin traspasos entre proveedores. Antes de firmar, confirma que el alcance acordado incluye el trabajo de planificación y revisión además de la ejecución de pruebas.
¿Los equipos pequeños necesitan un proceso de QA propio?
Un equipo pequeño necesita un proceso de QA ligero. Tres hábitos suelen cubrir lo básico: un plan de pruebas breve, un único lugar compartido para el seguimiento de errores y una regla clara sobre qué debe superarse antes de cada lanzamiento. Sin esa rutina, el testing se convierte en hacer clic al azar, y los mismos problemas vuelven en cada nueva versión.
Descubre cómo una plataforma de recetas electrónicas automatizó más de 40 pruebas con Playwright con alertas diarias en Slack y aumentó un 15% los pedidos de sus 700.000 pacientes.
