QA, sigla de Quality Assurance o aseguramiento de calidad, es el conjunto de actividades, procesos y herramientas que garantizan que un software cumple con los requisitos funcionales y no funcionales antes, durante y después de su entrega. A diferencia del simple "testing" o pruebas, QA cubre el ciclo completo desde la definición de requisitos hasta el monitoreo en producción.
En proyectos de desarrollo de software a medida, QA bien aplicado es la diferencia entre un producto que evoluciona sin sobresaltos y uno que acumula bugs en producción y deuda técnica que paraliza el roadmap. Esta guía explica qué es QA, cómo se organiza, qué tipos de pruebas existen y cuándo conviene incorporarlo.
QA vs testing: ¿son lo mismo?
No. Es una confusión común pero importante de desambiguar:
- Testing es la actividad puntual de ejecutar pruebas sobre el software para encontrar defectos. Es reactivo: probar lo que ya está construido.
- Quality Assurance (QA) es el proceso integral que previene defectos antes de que ocurran. Incluye revisión de requisitos, definición de criterios de aceptación, arquitectura de pruebas, automatización, métricas y mejora continua. Es proactivo.
- Quality Control (QC) es un subconjunto de QA enfocado en validar productos terminados.
Una empresa con cultura de QA no tiene "una persona que prueba al final del sprint". Tiene procesos donde la calidad se construye desde el primer commit.
Tipos de pruebas que conforman un programa de QA
Un programa de QA maduro combina varios tipos de pruebas, cada una enfocada en un nivel de la pirámide:
- Unit testing: prueba unidades aisladas de código (funciones, clases). Ejecutadas por desarrolladores. Frameworks: Jest, Vitest, RSpec, pytest.
- Integration testing: prueba interacciones entre módulos, APIs y servicios. Detecta bugs de integración que las pruebas unitarias no ven.
- End-to-end (E2E): simula recorridos reales de usuario sobre la aplicación completa. Frameworks: Playwright, Cypress, Selenium.
- Performance testing: mide tiempo de respuesta, throughput y comportamiento bajo carga. Herramientas: JMeter, k6, Artillery.
- Security testing: pentests, análisis estático (SAST) y dinámico (DAST), revisión de dependencias.
- Accessibility testing: validación de WCAG, lectores de pantalla, contraste, navegación por teclado.
- Manual exploratory testing: pruebas manuales no guionadas que detectan bugs que la automatización no captura (usabilidad, edge cases visuales).
QA manual vs QA automatizado
Esta no es una elección excluyente. Una operación de QA bien diseñada combina ambos:
- Automatización para regresión, smoke tests, CI/CD, cobertura de happy paths y casos críticos. Reduce time-to-market y evita romper lo que ya funciona.
- Manual exploratory para usabilidad, casos difícilmente automatizables, validación de UX y "pruebas intuitivas" que solo un humano detecta.
La pirámide clásica de Mike Cohn sugiere muchas pruebas unitarias en la base, menos integración en el medio y pocas E2E en la cima. Esta proporción mantiene tiempos de ejecución manejables y feedback rápido.
Métricas clave de QA
"Lo que no se mide no se mejora". Estas son las métricas más útiles para evaluar la salud de QA en un proyecto:
- Code coverage: porcentaje de líneas/ramas del código cubiertas por pruebas. Útil pero no suficiente; cobertura alta no garantiza calidad.
- Bug rate: bugs detectados por sprint vs sprints anteriores. Tendencia descendente = QA funcionando.
- Defect density: defectos por línea de código o por feature.
- Mean time to detect (MTTD): cuánto tarda en detectarse un bug desde que se introduce.
- Mean time to resolve (MTTR): cuánto tarda en resolverse un bug desde que se detecta.
- Escape rate: porcentaje de bugs que llegan a producción sin ser detectados antes.
Herramientas de QA modernas
El stack típico de QA en 2026 para una operación de software a medida en Chile suele combinar:
- Test runners: Jest / Vitest (JS/TS), pytest (Python), RSpec (Ruby), JUnit (Java).
- E2E: Playwright es el estándar moderno; Cypress sigue siendo válido. Selenium para casos legacy.
- API testing: Postman/Newman, REST-assured, Supertest.
- Performance: k6 para carga moderna, JMeter para flujos enterprise.
- CI/CD integration: GitHub Actions, GitLab CI, CircleCI corren las pruebas en cada PR.
- Test management: TestRail, Xray (Jira), Zephyr para gestión de casos de prueba en organizaciones grandes.
- Bug tracking: Jira, Linear, GitHub Issues.
¿Cuándo conviene incorporar QA en un proyecto?
La respuesta breve: desde el día 1. La respuesta larga depende del contexto:
- MVP de validación: testing manual exploratorio + algunos smoke tests automatizados. La velocidad importa más que la cobertura exhaustiva.
- Producto en producción con clientes pagantes: cobertura crítica de happy paths con E2E + integration + unit testing. Bug escape rate debe ir bajando sprint a sprint.
- Sistemas regulados (fintech, salud, legal): cobertura exhaustiva, documentación de pruebas, trazabilidad regulatoria, pentests periódicos. La Ley Fintech en Chile exige requisitos de calidad y ciberseguridad verificables.
- Plataformas con alto volumen transaccional: performance testing y stress testing son obligatorios.
QA-as-a-Service: tercerizar o construir interno
Hay tres modelos típicos para incorporar QA:
- QA interno permanente: contratar QA Engineers en planta. Ideal cuando el equipo es grande y el producto es central al negocio.
- QA dentro de squad nearshore: el QA es parte del squad de desarrollo desde el inicio. Es el modelo que aplicamos en nuestra software factory en Chile.
- QA como servicio externo (QAaaS): una empresa especializada audita o ejecuta pruebas a demanda. Útil para validaciones puntuales o pre-release.
El modelo más efectivo para empresas medianas chilenas suele ser el segundo: QA dentro del squad, donde la calidad no es una etapa sino una práctica permanente.
Errores comunes que destruyen un programa de QA
- Tratar QA como etapa final ("se prueba al final"). Para ese momento, los bugs ya cuestan 10x corregirlos.
- Medir solo code coverage. 90% de cobertura sin assertions útiles es teatro.
- Automatizar todo, sin manual exploratory. La automatización no encuentra bugs que ningún caso de prueba contempló.
- Ignorar pruebas de performance hasta que el sistema se cae. Mejor prevenir.
- No mantener las pruebas. Suite que falla intermitentemente termina siendo ignorada.
Conclusión
QA bien implementado es la diferencia entre un producto que escala y uno que se hunde en deuda técnica. No es un lujo de empresas grandes: cualquier proyecto de software a medida en producción se beneficia de tener QA desde el primer sprint, integrado al squad y con métricas medibles.
Si estás evaluando un partner para un proyecto donde QA tiene que ser parte del modelo desde el inicio, podemos mostrarte cómo operamos en nuestra software factory con QA como rol permanente del squad.
¿Necesitas un squad con QA integrado desde el primer sprint?
Trabajamos con squads donde QA está incorporado como rol permanente, no como etapa final. Cada sprint entrega código probado, con cobertura medible y bug rate trazable.
