El Ciclo de Vida del Desarrollo de Software para Ingenieros QA

"El usuario puede iniciar sesión" no es un criterio de aceptación testeable. "El usuario con credenciales válidas es redirigido a /dashboard en 3 segundos; el usuario con credenciales inválidas ve 'Email o contraseña inválidos'" sí lo es. Detectar esa brecha en la fase de requisitos cuesta una conversación; detectarla después del desarrollo cuesta un sprint. Este artículo cubre qué hacen realmente los QA engineers en cada una de las siete fases del SDLC, cuáles son los momentos de mayor impacto, y cómo varía el rol entre los modelos Waterfall, Agile y DevOps.

Las fases

1. Planificación

El proyecto está siendo delimitado. Se están escribiendo requisitos. Se están estableciendo presupuestos y plazos.

Qué hace QA aquí: En la mayoría de los equipos, poco. Eso es un problema. La mejor contribución de QA en la planificación es identificar los requisitos de testeabilidad temprano: ¿necesita la funcionalidad logging? ¿Acceso al entorno de prueba? ¿La capacidad de resetear el estado? Plantear esto en la planificación cuesta horas. Plantearlo durante el desarrollo cuesta días. Qué debería hacer QA: Asistir a las reuniones de planificación. Preguntar "¿cómo vamos a saber que esto funciona?" para cada funcionalidad propuesta. Señalar los requisitos que son poco claros o no son testeables.

2. Análisis de requisitos

Los requisitos están siendo refinados y especificados. Se escriben las historias de usuario. Se definen los criterios de aceptación.

Qué hace QA aquí: Revisar los criterios de aceptación para verificar su completitud. "El usuario puede iniciar sesión" no es testeable. "El usuario con credenciales válidas es redirigido a /dashboard en 3 segundos, el usuario con credenciales inválidas ve el error 'Email o contraseña inválidos'" sí lo es. Qué debería hacer QA: Escribir casos de prueba mientras se están finalizando los requisitos, no después. Plantear los casos extremos que faltan. Resistirse al lenguaje vago. Aquí es donde ocurre el trabajo de QA más valioso.

3. Diseño

Se está diseñando la arquitectura técnica. Esquema de base de datos. Contratos de API. Estructura de componentes. Topología de despliegue.

Qué hace QA aquí: Revisar el diseño para testeabilidad. ¿Puede el sistema probarse de forma aislada? ¿Hay APIs testeables o todo va por la UI? ¿Hay hooks de logging y observabilidad? ¿Hay una manera de inyectar datos de prueba? Qué debería hacer QA: Plantear preocupaciones de testeabilidad durante la revisión del diseño. "Esta funcionalidad no tiene API: solo puede probarse a través de la UI, lo que significa que cada test será lento y frágil. ¿Podemos añadir un endpoint de API o al menos una forma de preparar el estado de prueba?"

4. Implementación (desarrollo)

Los desarrolladores están escribiendo código. Se están construyendo las funcionalidades.

Qué hace QA aquí: Escribir casos de prueba en paralelo. Configurar entornos de prueba. Escribir tests automatizados para las funcionalidades a medida que están listas. Reportar bugs a medida que se encuentran. Qué debería hacer QA: Probar las funcionalidades de manera incremental, no todas de golpe al final. Trabajar con los desarrolladores para definir qué significa "listo para QA". Considerar el pair testing para funcionalidades complejas.

5. Testing

Las funcionalidades están completas y listas para verificación sistemática.

Qué hace QA aquí: Ejecutar casos de prueba, correr la automatización, hacer testing exploratorio, verificar correcciones de bugs, hacer testing de regresión en las áreas sin cambios. Qué debería hacer QA: Mantener un registro claro de defectos. Comunicar el riesgo claramente ("5 bugs de alta severidad abiertos, recomendamos no hacer release hasta que al menos 3 estén corregidos"). No solo encontrar bugs: ayudar a priorizarlos y comunicar su impacto.

6. Despliegue

El producto llega a los usuarios.

Qué hace QA aquí: Smoke testing en producción o staging después del deploy. Monitoreo de errores en producción. Validación rápida del camino crítico. Qué debería hacer QA: Tener un checklist de validación de despliegue. Saber cuáles 5-10 tests corren de inmediato después de cada deploy para confirmar que el sistema está saludable. Monitorear las herramientas de tracking de errores en las horas posteriores al release.

7. Mantenimiento

El producto está en producción y siendo mantenido. Correcciones de bugs, mejoras pequeñas, trabajo de rendimiento.

Qué hace QA aquí: Testing de regresión para cada cambio, por pequeño que sea. Mantener la suite de tests a medida que el producto evoluciona. Qué debería hacer QA: Actualizar los tests cuando cambian las funcionalidades. Retirar los tests de funcionalidades eliminadas. No dejar que la suite de tests se convierta en un museo de funcionalidades que nadie usa.

Modelos de SDLC

Waterfall

Todas las fases corren secuencialmente. Los requisitos están bloqueados antes de que empiece el diseño. El diseño está bloqueado antes de que empiece el desarrollo. El testing ocurre solo después de que el desarrollo está completo.

QA en Waterfall: QA es una fase al final. Esto produce los defectos más costosos: los bugs encontrados tarde son caros de corregir. Casi ningún equipo de software moderno usa Waterfall puro.

Agile (Scrum, Kanban)

El trabajo se hace en iteraciones cortas (sprints). Cada sprint incluye planificación, desarrollo y testing. Las funcionalidades se entregan de manera incremental.

QA en Agile: El testing ocurre dentro del sprint, no después. Los QA engineers son parte del equipo multifuncional. Este es el modelo dominante en 2026 para equipos de producto.

DevOps/Entrega continua

Integración continua y despliegue continuo. Los cambios de código disparan tests automatizados y pueden desplegarse a producción varias veces al día.

QA en DevOps: La automatización es esencial: no puedes verificar manualmente cada despliegue. Los QA engineers construyen y mantienen el pipeline de automatización. El foco se desplaza de la ejecución manual de tests hacia la estrategia de testing y la calidad de la automatización.

Por qué los QA engineers necesitan saber esto

Saber en qué fase del SDLC estás te dice qué tipo de trabajo de QA es más valioso en este momento.

En planificación: revisión de requisitos. En desarrollo: escritura temprana de casos de prueba. Post-despliegue: smoke testing. Un QA engineer que solo sabe ejecutar casos de prueba en la fase de testing es útil solo en una de siete fases. Un QA engineer que entiende el SDLC completo puede añadir valor en cada etapa.

Por eso "shift-left" se ha convertido en la filosofía de QA dominante: mover el testing más temprano en el SDLC, donde es más barato y tiene más impacto.