Introducción
El ciclo de vida del software (SDLC) es el proceso estructurado que los equipos de desarrollo usan para planificar, construir, probar y lanzar software de forma predecible. Se divide en fases — generalmente 7 — y cada una produce entregables concretos que alimentan la siguiente.
El problema no es si el SDLC se usa o no. Es dónde aparece el QA dentro de él. En la mayoría de los proyectos, las pruebas llegan en la quinta o sexta fase, cuando el código ya está escrito. Un bug detectado en esa fase puede costar hasta 400 veces más que el mismo bug detectado en la fase de análisis de requisitos (IBM Systems Sciences Institute / NIST, 2026).
Esta guía explica las 7 fases, los modelos más usados — cascada, ágil, DevOps — y exactamente dónde el QA cambia el resultado.
Las 7 fases del ciclo de vida del software
El SDLC organiza el desarrollo en pasos secuenciales con objetivos y entregables definidos. Aquí el mapa completo con el rol de QA en cada fase:
| Fase | Qué ocurre | Entregable principal | Dónde entra QA |
|---|---|---|---|
| 1. Planificación | Objetivos, alcance, recursos, riesgos | Plan de proyecto | Verificar que hay tiempo y recursos reales para probar |
| 2. Análisis | Qué debe hacer el sistema, con qué criterios | Especificación de requisitos | Revisar ambigüedades en criterios de aceptación — el bug más barato de corregir |
| 3. Diseño | Arquitectura, modelo de datos, flujos | Documento técnico de diseño | Detectar riesgos de calidad antes de escribir código |
| 4. Desarrollo | Se escribe el código | Código fuente | Testing unitario integrado al proceso de escritura (shift-left) |
| 5. Pruebas | Se verifica que el software cumple requisitos | Reportes de defectos | Fase central: funcional, integración, rendimiento, seguridad, accesibilidad |
| 6. Despliegue | El software llega a producción | Software en producción | Pruebas de humo post-deploy para verificar que el lanzamiento no rompió nada |
| 7. Mantenimiento | Correcciones, mejoras, monitoreo | Versiones de corrección | Análisis de defectos para retroalimentar la próxima iteración |
¿Por qué la Fase 2 (análisis de requisitos) es la más importante para QA?
Un requisito mal definido es el origen del bug más barato de corregir y más caro de ignorar. En la fase de análisis, un revisor de QA detecta en minutos lo que, si llega a código, puede costar días de retrabajo.
Ejemplo concreto: un requisito que dice 'el sistema debe ser rápido' no se puede probar. Un analista de QA lo convierte en: 'el tiempo de respuesta de la búsqueda principal no debe superar 2 segundos bajo 500 usuarios concurrentes'. Esa precisión determina si hay un criterio de aceptación real o una aspiración.
El 52% de los proyectos de software supera su alcance original (Guru99, 2025). La causa más frecuente: requisitos que cambian después de que el desarrollo empezó, porque nadie los definió con suficiente precisión al inicio.
¿En qué fase se detectan los bugs más caros?
En producción. Y el costo no escala linealmente — escala exponencialmente.
La curva documentada por IBM Systems Sciences Institute y validada por NIST muestra lo siguiente:
- Bug detectado en codificación: ~25 USD
- Bug detectado en integración: ~150 USD
- Bug detectado en testing/staging: 600–1.000 USD
- Bug detectado en producción: +10.000 USD
La razón es estructural: en producción, corregir un bug implica diagnosticar el problema, reescribir código, volver a probar, hacer un hotfix deploy, comunicar el incidente y, en algunos casos, gestionar el impacto en usuarios o reguladores. El mismo problema en la fase de codificación es una corrección de 10 minutos.
El 85% de los bugs de software son detectados por los propios usuarios, no durante las pruebas (e2easy, 2026). Si los usuarios son el equipo de QA, el ciclo de vida del software tiene un problema de diseño.
Modelo cascada vs. modelo ágil: ¿cuál cambia el rol del QA?
Las 7 fases existen en ambos modelos. Lo que cambia es cómo se organizan en el tiempo y cuándo puede intervenir el QA.
Cascada
Las fases se ejecutan de forma secuencial. El QA entra en la fase 5, cuando el código ya está completo. Si se encuentra un problema de diseño en esa fase, el costo de corregirlo es alto porque implica retroceder varias fases. Funciona cuando los requisitos son muy estables desde el inicio — proyectos de infraestructura, sistemas regulados con especificaciones fijas.
Ágil
Las 7 fases se comprimen en ciclos cortos (sprints de 1-4 semanas). Al final de cada sprint hay software funcional y probado. El QA participa desde el inicio de cada sprint — revisa los criterios de aceptación antes de que empiece el desarrollo, ejecuta pruebas durante el sprint y valida antes del deploy. El 97% de las organizaciones usa algún grado de metodología ágil. Los proyectos ágiles muestran tasas de éxito del 75% frente al 56% de los enfoques en cascada.
DevOps y CI/CD
DevOps no reemplaza el SDLC: lo automatiza. Las pruebas se integran en el pipeline de integración continua y se ejecutan en cada commit. El objetivo es que el ciclo completo (desde el commit hasta producción) tarde horas, no semanas. QA en DevOps significa que las pruebas no esperan al final del sprint — corren automáticamente con cada cambio de código.
¿Qué modelos del ciclo de vida del software existen?
Además de cascada y ágil, existen variantes específicas para distintos contextos:
- Espiral: combina diseño iterativo con análisis de riesgos en cada vuelta. Útil para proyectos de alta complejidad o incertidumbre técnica.
- Incremental: el sistema se construye y entrega en módulos funcionales progresivos. Permite tener versiones usables antes de que el producto esté completo.
- Prototipado: se construye un prototipo funcional para validar requisitos con el usuario antes de desarrollar el sistema completo.
- ISO/IEC 12207: el estándar internacional que define los procesos del ciclo de vida del software. Define no solo las fases de desarrollo sino también los procesos de soporte (documentación, gestión de configuración, aseguramiento de calidad) y organizacionales.
La elección del modelo depende del tipo de proyecto, la estabilidad de los requisitos y el nivel de riesgo tolerable. No existe un modelo universalmente correcto.
¿Cómo saber si el ciclo de vida de tu equipo tiene un problema de QA?
Hay señales que se repiten en equipos con QA mal integrado:
- Los mismos tipos de bugs aparecen en producción repetidamente — indica que no hay análisis de causa raíz ni retroalimentación al ciclo
- Las releases se retrasan por bugs encontrados en las últimas semanas — el QA se comprime al final del ciclo en lugar de distribuirse
- Los desarrolladores no saben qué probar — los criterios de aceptación de la fase 2 son ambiguos
- Hay cobertura de tests pero los bugs llegan igual a producción — los tests automáticos existen pero no cubren los casos que realmente fallan
- El equipo de QA trabaja en silos, separado del equipo de desarrollo — el testing es un bloqueo al final, no parte del proceso
Si reconoces más de uno de estos síntomas, el problema no es técnico. Es de proceso. El diagnóstico de madurez QA (ver /recursos/diagnostico-de-madurez-qa/) es el primer paso para entender dónde está el cuello de botella específico.
Conclusión: el SDLC no falla por el proceso, sino por dónde entra el QA en él
El ciclo de vida del software es la estructura que hace predecible el desarrollo. El QA es la función que hace confiable el resultado. Cuando el QA entra tarde — en la fase 5, cuando el código ya está escrito — el costo de los problemas se multiplica porque cada fase que se saltó acumula deuda que hay que pagar con intereses en producción.
Los equipos que integran QA desde la fase de análisis de requisitos no solo detectan bugs más baratos: también producen software con menos bugs totales, porque el proceso de definir cómo se va a probar algo obliga a pensar con más precisión en qué debe hacer ese algo.
Si quieres saber en qué punto del ciclo está fallando tu equipo, el diagnóstico de madurez QA de Aliwen evalúa 5 dimensiones en 10 preguntas.