Introducción
QA (Quality Assurance) es el conjunto de procesos que garantiza que el software cumple sus requisitos de funcionamiento antes de llegar a los usuarios. No es solo encontrar bugs — es el sistema que previene que los bugs lleguen a producción en primer lugar.
Sin QA, el equipo de desarrollo entrega código que alguien probará eventualmente. El problema es quién lo prueba: si son los usuarios finales, el costo de cada falla se multiplica porque ya está en producción. Los equipos que integran QA en el proceso de desarrollo detectan los problemas donde cuestan menos — antes de que el código exista, no después de que falle.
¿Qué diferencia QA de testing?
Es una distinción que confunde a muchos equipos. Testing es una actividad específica dentro del QA: verificar que el software funciona según lo esperado ejecutando pruebas. QA es el proceso completo que incluye el testing pero va más allá.
- Testing: ejecutar casos de prueba, verificar resultados, reportar defectos
- QA: definir los criterios de calidad, diseñar los procesos para cumplirlos, verificar que el equipo los sigue y medir si se están cumpliendo
Un equipo que solo hace testing detecta bugs. Un equipo con QA reduce la cantidad de bugs que se producen. La diferencia no es semántica — tiene consecuencias directas en el costo y la velocidad del desarrollo.
La distinción con QC (Quality Control) también es relevante: QC verifica que el producto final cumple los estándares. QA verifica que el proceso de producción está diseñado para producir calidad. QA es preventivo, QC es correctivo. Ambos son necesarios; QA es el que más impacto tiene en el largo plazo.
¿Qué hace un equipo de QA exactamente?
Un equipo de QA en un proyecto de software de mediana complejidad hace lo siguiente:
- Revisa los requisitos antes de que empiece el desarrollo para detectar ambigüedades, criterios de aceptación incompletos y casos edge no considerados
- Diseña la estrategia de testing: qué se va a probar, con qué nivel de cobertura, con qué herramientas y en qué orden
- Ejecuta pruebas funcionales, de integración, de rendimiento, de seguridad y de accesibilidad según el alcance del proyecto
- Reporta y hace seguimiento de defectos hasta que están corregidos y verificados
- Integra testing automatizado en el pipeline CI/CD para que cada deploy tenga cobertura sin necesitar intervención manual
- Mide métricas de calidad: tasa de defectos, cobertura de tests, tiempo de corrección, deuda técnica
El alcance específico depende del tamaño del equipo, la madurez del proceso y el tipo de sistema. No todos los proyectos necesitan el mismo QA — un sistema de pagos financiero tiene requisitos de calidad muy distintos a una herramienta interna de gestión.
¿Cuándo una empresa necesita QA?
La respuesta corta: antes de que los problemas lleguen a los usuarios. La respuesta más útil: cuando alguna de estas condiciones se cumple.
- Los releases generan bugs en producción de forma recurrente — señal de que el testing es insuficiente o llega demasiado tarde
- El equipo de desarrollo dedica más tiempo a corregir bugs reportados por usuarios que a desarrollar nuevas funcionalidades
- El sistema maneja datos sensibles, transacciones financieras o información de salud — donde una falla tiene consecuencias regulatorias o de reputación
- El producto escala y el testing manual ya no alcanza a cubrir todos los casos en el tiempo de sprint
- Hay presión de fechas que lleva a reducir el tiempo de pruebas para entregar antes
El último punto es el más común y el más peligroso. Recortar QA para entregar más rápido no acelera el proyecto — desplaza el costo al momento más caro del ciclo: producción.
¿Qué tipos de QA existen?
Dentro del aseguramiento de calidad de software, hay varios tipos según el objeto de verificación:
- Testing funcional: verifica que el software hace lo que los requisitos dicen que debe hacer
- Testing no funcional: verifica atributos de calidad que no son funcionalidades — rendimiento, seguridad, accesibilidad, usabilidad
- Testing de regresión: verifica que los cambios recientes no rompieron funcionalidades que antes funcionaban correctamente
- Testing de integración: verifica que los componentes del sistema funcionan correctamente cuando se conectan entre sí
- Testing de aceptación: verifica que el sistema cumple los criterios de aceptación definidos por el cliente o el negocio
- Testing de rendimiento: verifica el comportamiento del sistema bajo distintos niveles de carga — ver /recursos/pruebas-de-carga/
- Testing de seguridad: verifica que el sistema no tiene vulnerabilidades explotables
¿QA manual o automatizado?
La respuesta correcta es: ambos, en el rol que les corresponde.
El testing automatizado ejecuta con rapidez los casos repetitivos — regresión, humo, integración — y da feedback rápido en el pipeline CI/CD. El testing manual es insustituible para la exploración, la usabilidad y los casos edge que nadie documentó porque nadie anticipó que ocurrirían.
Los equipos que intentan automatizar todo terminan con suites de tests frágiles que nadie mantiene. Los que dependen solo del testing manual no pueden escalar cuando el producto crece. El criterio de decisión es práctico: automatizar lo que es estable, repetitivo y crítico; mantener el testing exploratorio manual para lo que requiere juicio humano.
Para una comparación detallada, ver /recursos/testing-automatizado-vs-manual/.
¿Cómo medir si el QA está funcionando?
Un proceso de QA sin métricas es una promesa. Las métricas que indican si el proceso funciona:
- Tasa de defectos escapados a producción: cuántos bugs por cada 100 funcionalidades llegan a los usuarios finales. Si sube, el QA no está cumpliendo su rol preventivo
- Costo de corrección por fase: si la mayoría de los bugs se corrigen en producción, el QA está llegando demasiado tarde
- Cobertura de tests automatizados: qué porcentaje del código crítico tiene cobertura de tests automáticos que corren en el pipeline
- Tiempo medio de detección: cuánto tarda el equipo en detectar un bug desde que se introduce en el código
Ninguna métrica por sí sola cuenta toda la historia. La combinación de estas cuatro da una imagen real del estado del QA en el equipo.
Para saber en qué nivel de madurez está el QA de tu equipo en estas dimensiones, el Diagnóstico de Madurez QA de Aliwen evalúa 5 dimensiones en 10 preguntas.