Quality Assurance y Quality Control: dos pilares complementarios

¿Proceso o Producto?

En muchos proyectos de software se habla de calidad como si fuera un concepto abstracto o un cajón de sastre donde entra todo. Dentro de esa ambigüedad, los términos Quality Assurance (QA) y Quality Control (QC) se utilizan con demasiada frecuencia como sinónimos, cuando en realidad describen funciones distintas y complementarias.

Equiparar QA con QC no es una mera cuestión terminológica, es un riesgo operativo. Cuando los límites entre ambos se desdibujan:

• Se generan responsabilidades difusas.

• Se diseñan procesos incompletos.

• Se termina apoyando toda la calidad del proyecto en las pruebas del final.

El resultado suele ser previsible: entregas con más riesgo del necesario, dependencia excesiva de «héroes de última hora» y dificultad para explicar al cliente qué se está haciendo realmente para garantizar la calidad.

Distinguir con precisión qué es QA, qué es QC y cómo se relacionan permite construir una estrategia de calidad robusta. QA se ocupa de la forma en la que se trabaja. QC se ocupa de comprobar el resultado de ese trabajo. Solo cuando ambos están bien definidos y coordinados se puede hablar de una garantía real, tanto técnica como procedimental.

Qué es Quality Assurance

Quality Assurance (QA) es el marco de procesos, normas, criterios y prácticas que una organización establece para asegurar que el software se construye de manera controlada, predecible y repetible. Su propósito principal es prevenir defectos antes de que lleguen al producto y reducir la variabilidad en la forma de trabajar.

QA opera sobre la forma de trabajar de los equipos. Define:

1. Cómo se recogen y se aprueban los requisitos.

2. Qué estándares de diseño y de código deben respetarse.

3. Cómo se gestionan los cambios.

4. De qué manera se planifican las entregas.

5. Bajo qué condiciones se considera que una funcionalidad está terminada (Definition of Done).

Todo esto no se centra en un proyecto concreto, sino que constituye la base sobre la que se apoyan todos los desarrollos de la organización.

En un enfoque maduro de QA se suelen encontrar varios elementos recurrentes:

• Políticas de calidad claras: Marcan estándares de codificación, criterios de diseño, reglas de seguridad y requisitos de accesibilidad o cumplimiento normativo.

• Procesos formalizados: Describen con detalle cómo se pasa de la idea inicial al software desplegado.

• Definiciones explícitas: Cuándo un requerimiento está preparado para desarrollo y cuándo una tarea está realmente finalizada.

• Roles y responsabilidades delimitados: Se sabe quién revisa requisitos, quién valida diseños, quién revisa código y quién autoriza un despliegue.

También forman parte del QA las revisiones y auditorías de proceso. No se trata solo de mirar el producto final, sino de analizar cómo se ha trabajado: qué incidencias se han producido, qué decisiones se han tomado, qué pasos se han omitido, qué riesgos se han aceptado. A partir de ese análisis se impulsa la mejora continua mediante ajustes en procedimientos, formación específica o revisión de estándares.

En el día a día, la presencia de un QA bien implantado se percibe cuando no se empieza a desarrollar sin requisitos claros, cuando no se integra código sin revisión previa, cuando no se despliega una versión sin un plan de pruebas asociado ni sin un protocolo de vuelta atrás definido, y cuando ningún proyecto arranca sin una estrategia de calidad explícita.

Qué es Quality Control

Quality Control (QC) se centra en el producto que se entrega. Su misión es verificar y validar que el software desarrollado cumple los requisitos funcionales y no funcionales acordados, así como los estándares de calidad adoptados por la organización.

Mientras QA intenta evitar que los defectos aparezcan, QC se ocupa de detectar los defectos que han llegado a materializarse. Para ello se apoya en actividades de verificación y validación que se realizan sobre el propio producto o sobre incrementos del mismo. El objetivo no es solo encontrar errores, sino aportar una visión objetiva del estado real de cada versión que se pretende liberar.

QC se concreta sobre todo en el diseño, ejecución y mantenimiento de pruebas. Incluye:

• Pruebas unitarias.

• Pruebas de integración y de sistema.

• Pruebas de regresión.

• Pruebas de aceptación de usuario (UAT).

• Pruebas de rendimiento, seguridad, compatibilidad o accesibilidad.

Estas pruebas pueden ser manuales o automatizadas, y en la práctica suele combinarse ambas aproximaciones para optimizar cobertura, profundidad y coste.

Otro pilar del QC es la trazabilidad frente a requisitos. Cada caso de prueba se relaciona con uno o varios requerimientos o historias de usuario, lo que permite conocer qué partes del sistema han sido verificadas y con qué resultado. Esa trazabilidad es esencial para responder preguntas críticas como qué impacto tiene un cambio, qué riesgos implica liberar con determinadas incidencias abiertas o qué grado de cobertura tiene una funcionalidad clave.

La gestión de defectos también pertenece al ámbito del QC. Implica registrar cada incidencia, clasificar su gravedad y prioridad, seguir su ciclo de vida hasta la resolución y documentar la causa raíz y las decisiones tomadas. A partir de estos datos se puede valorar la estabilidad de una versión y priorizar esfuerzos de corrección.

Finalmente, QC genera informes de calidad que resumen resultados de pruebas, estado de defectos, áreas de riesgo y grado de preparación de una versión. Estos informes son los que permiten tomar decisiones informadas sobre si una entrega está lista para pasar a la siguiente fase o para llegar a producción.

Diferencias fundamentales entre QA y QC

Aunque QA y QC forman parte de la misma disciplina de gestión de la calidad, sus enfoques son distintos y conviene entender bien esa diferencia.

1. Enfoque Preventivo vs. Detectivo:

QA actúa sobre el proceso y tiene un carácter preventivo. Su pregunta clave es: ¿Se está trabajando de la forma correcta para que el resultado sea fiable? Define reglas, estándares, flujos y controles que se aplican desde el inicio del ciclo de vida del proyecto hasta la operación del sistema en producción. Afecta a toda la organización, no solo al equipo de pruebas.

QC actúa sobre el producto y tiene un carácter detectivo. Su pregunta clave es: ¿Lo que se ha construido funciona realmente como se espera? Se apoya en pruebas, inspecciones y análisis del comportamiento del software. Su foco se intensifica en las fases de verificación y validación.

2. Los Entregables:

QA produce: Políticas, procesos, normas, plantillas y acuerdos de servicio. El QA diseña el sistema de trabajo.

QC produce: Casos de prueba, evidencias de ejecución, registros de defectos e informes de calidad. El QC mide el resultado de ese sistema sobre el producto real.

3. El Impacto:

Un buen QA se traduce en estabilidad organizativa, capacidad de repetir éxitos, reducción de improvisaciones y menor dependencia de personas concretas.

Un buen QC se traduce en menos defectos visibles por el usuario, en menos incidencias críticas en producción y en más confianza en cada versión liberada.

No se trata de elegir entre QA o QC, sino de reconocer que la calidad completa exige la presencia equilibrada de ambos.

Cómo se complementan QA y QC en el ciclo de vida del proyecto

La relación entre QA y QC se comprende con claridad si se recorre un proyecto de principio a fin.

• Descubrimiento y análisis

En las fases iniciales, QA define cómo se van a recoger, documentar y aprobar los requisitos. Indica qué se considera un requerimiento bien formado, qué información debe contener, quién debe validarlo y cómo se prioriza.

En ese mismo momento, QC puede empezar a colaborar transformando estos requisitos en escenarios de prueba y en criterios de aceptación claros. Esta colaboración temprana reduce ambigüedad, evita malentendidos y asegura que lo que se define desde negocio será comprobable en fases posteriores.

• Diseño y arquitectura

Durante esta fase, QA asegura que se aplican los estándares de diseño y de seguridad establecidos, que la solución resultante es coherente con la estrategia de la organización y que el sistema será testeable (observabilidad, modularidad, aislamiento de dependencias).

QC aporta la visión práctica de qué pruebas serán necesarias, qué cargas de trabajo deben simularse, qué integraciones pueden ser más frágiles o qué combinaciones de dispositivos y sistemas operativos hay que contemplar.

• Desarrollo

Aquí QA define el flujo de trabajo de código y de cambios. Establece qué uso se hace de las ramas, qué condiciones debe cumplir una solicitud de integración para poder aceptarse, qué herramientas de análisis estático deben ejecutarse y qué umbrales mínimos de calidad de código se exigen.

QC, por su parte, colabora en la definición y ejecución de pruebas unitarias e integradas, desarrolla y mantiene suites de pruebas automatizadas funcionales y no funcionales y se involucra en la validación continua de los incrementos.

• Validación y preproducción

Cuando el proyecto entra en esta fase, QA marca la estrategia global de pruebas: qué tipos de pruebas se van a ejecutar, qué entornos se van a utilizar, qué datos se emplearán y qué criterios de entrada/salida tiene cada fase.

QC ejecuta esa estrategia, recoge resultados, gestiona incidencias y construye informes que reflejan el estado real de la versión: qué funciona, qué no, qué partes no se han podido probar y qué riesgo residual queda si se decide liberar.

• Despliegue y operación

En la fase final, QA define los procedimientos de puesta en producción, los planes de vuelta atrás (rollback), la forma de registrar incidencias y la dinámica de revisión post-incidente.

QC ejecuta pruebas de humo tras un despliegue, comprueba que las funcionalidades críticas se comportan como se espera en el entorno real y analiza los defectos detectados en producción para alimentar la mejora continua.

De esta manera, QA diseña el marco y QC proporciona información real sobre cómo se comporta el producto dentro de ese marco. Esa información vuelve al ámbito del QA para ajustar procesos, normas y prácticas. El resultado es un ciclo de aprendizaje continuo.

Calidad técnica y calidad procedimental: una doble garantía

Cuando un cliente pregunta por las garantías de un proyecto no se refiere únicamente a que el software funcione correctamente en el momento de la entrega. Lo que realmente busca es la seguridad de que el servicio se presta bajo un sistema de trabajo sólido, que reduce la probabilidad de incidentes graves y que permite reaccionar con rapidez y orden.

La combinación de QA y QC bien implantados permite ofrecer esa doble garantía:

En el plano técnico (QC) Una estrategia de pruebas clara, la presencia de automatización en los niveles adecuados, el uso de estándares de código y la existencia de monitorización y alarmas proporcionan una barrera muy eficaz frente a defectos críticos en producción. Además, cuando aparece un problema, disponer de trazas y métricas facilita el análisis de causa raíz.

En el plano procedimental (QA) La existencia de procesos definidos, roles claros y criterios de aceptación documentados aporta estabilidad y trazabilidad. Se puede reconstruir cómo se ha trabajado en cada versión, qué decisiones se han tomado y qué riesgos se han asumido. Esto reduce la dependencia de conocimiento no documentado («conocimiento tribal») y permite replicar buenas prácticas.

QC aporta confianza en el producto que se entrega hoy. QA asegura que la forma de trabajar permite seguir entregando productos con la misma calidad mañana.

Métricas y gobierno de la calidad

Para que QA y QC sean algo más que buenas intenciones es necesario medir y gobernar.

Desde la perspectiva del QC, resulta útil observar indicadores como:

• El número de defectos por versión.

• La proporción de defectos críticos detectados en fases tempranas vs. producción.

• La estabilidad de las regresiones.

• La cobertura funcional alcanzada por las pruebas automatizadas.

• El tiempo medio de resolución de incidencias. Estos datos permiten evaluar el nivel de riesgo que implica cada entrega.

Desde la perspectiva del QA, tienen valor métricas como:

• El porcentaje de requisitos que entran en desarrollo cumpliendo los criterios de preparación.

• La cantidad de código que se integra sin revisión previa.

• El volumen de retrabajo debido a cambios mal gestionados.

• El número de incidencias asociadas a incumplimientos de proceso.

• El grado de adopción real de los estándares definidos. Estos indicadores permiten identificar en qué puntos del proceso se originan los problemas.

El gobierno de la calidad consiste en revisar estas métricas con una cadencia apropiada, analizarlas en su contexto y tomar decisiones concretas a partir de ellas. Esto puede traducirse en ajustar la estrategia de pruebas, reforzar la formación o simplificar procesos.

La excelencia operativa requiere la integración estratégica de Quality Assurance (QA) y Quality Control (QC). Operar únicamente con QC conlleva costes correctivos elevados por su naturaleza reactiva, mientras que limitarse a QA genera marcos teóricos sin validación empírica. Al unificar ambos enfoques, la calidad deja de ser circunstancial para convertirse en un sistema de gestión robusto, cuantificable y orientado a la mejora continua.