Que es el SDLC?
El Ciclo de Vida de Desarrollo de Software (SDLC) es un framework que define el proceso para planificar, crear, probar y desplegar software. Diferentes modelos SDLC describen diferentes enfoques para organizar estas actividades.
Entender los modelos SDLC es esencial para testers porque tu enfoque de testing esta determinado por el modelo de desarrollo que sigue tu equipo. Cuando testeas en un proyecto Waterfall, tus actividades, tiempos y entregables son fundamentalmente diferentes de testear en un proyecto Agile.
En esta leccion exploramos el modelo SDLC mas antiguo y estructurado: Waterfall.
El Modelo Waterfall
El modelo Waterfall fue descrito por primera vez por Winston Royce en 1970 (aunque ironicamente, Royce lo presento como ejemplo de un enfoque defectuoso). A pesar de eso, se convirtio en la metodologia dominante de desarrollo por decadas.
Waterfall es un modelo secuencial y lineal. Cada fase debe completarse totalmente antes de que comience la siguiente. Como el agua fluyendo sobre rocas en una cascada, el progreso fluye en una direccion — hacia abajo.
Que construir] --> D[Diseno
Como construirlo] D --> I[Implementacion
Construirlo] I --> T[Testing
Verificar que funciona] T --> Dep[Despliegue
Lanzarlo] Dep --> M[Mantenimiento
Soportarlo] style R fill:#3b82f6,color:#fff style D fill:#6366f1,color:#fff style I fill:#8b5cf6,color:#fff style T fill:#a855f7,color:#fff style Dep fill:#d946ef,color:#fff style M fill:#ec4899,color:#fff
Las Seis Fases
1. Requisitos
El proyecto comienza recopilando y documentando todos los requisitos. Analistas de negocio, product managers y stakeholders definen que debe hacer el sistema. El resultado es un documento detallado de especificacion de requisitos (SRS).
Participacion de QA: Los testers revisan requisitos por testabilidad, completitud, consistencia y ambiguedad. Comienzan a escribir planes de prueba de alto nivel.
2. Diseno
Arquitectos y desarrolladores senior disenan el sistema basandose en los requisitos. Esto incluye arquitectura del sistema, esquemas de base de datos, contratos de API, wireframes de UI y elecciones tecnologicas.
Participacion de QA: Los testers revisan documentos de diseno y comienzan a disenar casos de prueba. Los arquitectos de testing planifican el entorno e infraestructura de pruebas.
3. Implementacion (Codificacion)
Los desarrolladores escriben el codigo segun la especificacion de diseno. Esta es tipicamente la fase mas larga. Los desarrolladores pueden escribir unit tests, pero el testing formal se reserva para la siguiente fase.
Participacion de QA: Limitada durante la codificacion. Los testers finalizan casos de prueba, preparan datos de prueba y configuran entornos de testing.
4. Testing
Despues de completar la implementacion, el sistema se entrega al equipo de testing. Los testers ejecutan casos de prueba, realizan testing de integracion, testing de sistema y reportan defectos. Los desarrolladores corrigen bugs y los testers re-verifican.
Participacion de QA: Esta es la fase activa principal del equipo QA. Se ejecutan todos los casos planificados, se registran y rastrean defectos, y se produce un reporte resumen de testing.
5. Despliegue
Una vez completado el testing y que el producto cumple los criterios de aceptacion, se despliega a produccion. Esto puede incluir testing de aceptacion de usuario (UAT).
Participacion de QA: Smoke testing en produccion, monitoreo de problemas relacionados con el despliegue.
6. Mantenimiento
Despues del despliegue, el equipo proporciona soporte continuo — corrigiendo bugs reportados por usuarios, lanzando parches y ocasionalmente agregando funcionalidades menores.
Participacion de QA: Testing de regresion para cada release de mantenimiento, verificacion de correcciones.
Ventajas de Waterfall
Estructura clara y milestones definidos. Cada fase tiene entregables y criterios de salida definidos. La gerencia puede rastrear el progreso facilmente.
Documentacion completa. Waterfall produce documentacion detallada en cada etapa. Esto es valioso para compliance, incorporacion de nuevos miembros y mantenimiento a largo plazo.
Plazos y presupuestos predecibles. Como todos los requisitos se definen al inicio, es mas facil estimar costos y plazos.
Funciona bien para industrias reguladas. Dispositivos medicos (FDA), aviacion (DO-178C), defensa y contratos gubernamentales frecuentemente requieren la trazabilidad que Waterfall proporciona naturalmente.
Simple de entender y gestionar. La naturaleza lineal hace que Waterfall sea intuitivo.
Desventajas de Waterfall
Testing tardio. El mayor problema para QA: el testing ocurre al final. Si las decisiones fundamentales de diseno estan equivocadas, se descubren tarde cuando corregirlas es extremadamente costoso.
Sin software funcional hasta tarde. Los stakeholders no ven un producto funcional hasta la fase de Testing o Despliegue.
Mal manejo del cambio. Waterfall asume que los requisitos son completos y estables desde el inicio. En realidad, las necesidades cambian.
Integracion big-bang. Todos los componentes se integran de una vez durante la fase de Testing, dificultando aislar problemas.
Alto riesgo. Si un error critico en requisitos no se detecta hasta el testing, el proyecto entero puede necesitar retrabajo significativo.
Como Encaja el Testing en Waterfall
| Fase | Actividad QA | Entregable |
|---|---|---|
| Requisitos | Revisar requisitos, escribir plan de pruebas | Plan de Pruebas |
| Diseno | Revisar diseno, disenar casos de prueba | Casos de Prueba |
| Implementacion | Preparar entorno, finalizar datos de prueba | Entorno, Datos |
| Testing | Ejecutar pruebas, reportar defectos, re-testear | Reporte de Ejecucion, Defectos |
| Despliegue | Smoke testing, soporte UAT | Reporte de Verificacion |
| Mantenimiento | Testing de regresion | Reporte de Regresion |
La Compresion de la Fase de Testing
Un problema bien conocido en Waterfall: la fase de testing se comprime. El desarrollo se atrasa (casi siempre), pero la fecha de despliegue permanece fija. Resultado: la fase de testing — originalmente planificada para 4 semanas — se reduce a 2 semanas.
Esta presion lleva a:
- Cobertura de testing reducida
- Priorizar solo testing del happy-path
- Omitir testing no-funcional (rendimiento, seguridad)
- Testers trabajando horas extra
- Bugs diferidos en lugar de corregidos
Este patron es una de las motivaciones principales para adoptar modelos iterativos y Agile.
Cuando Funciona Bien Waterfall
A pesar de sus limitaciones, Waterfall sigue siendo apropiado en ciertos contextos:
- Proyectos de cumplimiento regulatorio donde la documentacion y trazabilidad son obligatorias
- Integracion hardware-software donde los componentes de hardware tienen largos tiempos de fabricacion
- Dominios bien entendidos con requisitos estables y bien documentados
- Contratos de precio fijo donde el alcance debe definirse antes del desarrollo
- Proyectos pequenos con requisitos claros y simples
Ejercicio: Identifica Problemas de Waterfall
Lee el siguiente caso de estudio e identifica al menos 5 problemas causados por usar Waterfall:
Caso de Estudio: Sistema de Gestion de Pacientes Hospitalarios
Un hospital contrato a una empresa de software para construir un sistema de gestion de pacientes usando Waterfall:
- Mes 1-2: Requisitos recopilados de administradores (doctores y enfermeras no fueron consultados)
- Mes 3-4: Sistema disenado con interfaz desktop-first
- Mes 5-8: Desarrollo completado
- Mes 9-10: Testing comenzo — 47 bugs criticos encontrados, incluyendo pantallas que requerian 25+ clics para tareas comunes
- Mes 10: Administradores vieron el sistema por primera vez y solicitaron 30+ cambios
- Mes 11: Deadline alcanzada. Sistema desplegado con defectos conocidos. Enfermeras se negaron a usarlo.
Pista
Considera: participacion de stakeholders, calidad de requisitos, feedback tardio, timing del testing y aceptacion del usuario.Solucion
Participacion incompleta de stakeholders: Solo administradores fueron consultados. Doctores y enfermeras — los usuarios principales — fueron excluidos, garantizando que el sistema no satisfaria necesidades reales.
Sin validacion temprana: No se mostraron prototipos a usuarios reales hasta el mes 10. Diez meses de trabajo basados en suposiciones.
Testing tardio descubrio problemas fundamentales: 47 bugs criticos y 25+ clics sugieren problemas de diseno, no solo bugs de codificacion. Encontrados demasiado tarde.
El cambio de requisitos era inevitable pero no planificado: Los 30+ cambios solicitados en el mes 10 eran predecibles.
Compresion de la fase de testing: La fase fue comprimida al acercarse la deadline, resultando en defectos conocidos enviados a produccion.
Sin feedback iterativo: Un prototipo funcional en el mes 4 habria descubierto los problemas de flujo 6 meses antes.
Asuncion desktop-first incorrecta: El personal hospitalario se mueve entre estaciones, pero esta asuncion se incorporo en el diseno sin cuestionarse.
Un enfoque iterativo habria detectado la mayoria de estos problemas en los primeros 2-3 meses.
Tips Profesionales
Tip 1: Incluso en Waterfall, insiste en actividades de testing temprano. No puedes controlar el modelo SDLC, pero puedes abogar por revisiones de requisitos, revisiones de diseno y prototipos tempranos.
Tip 2: Documenta todo — es la fortaleza de Waterfall. En Waterfall, la documentacion no es sobrecarga — es una funcionalidad. Escribe planes de prueba completos, casos detallados y reportes de defectos exhaustivos.
Tip 3: Negocia tiempo de testing en el plan del proyecto. Si estas en un proyecto Waterfall, lucha por tiempo adecuado de testing en la etapa de planificacion. Una vez fijado el cronograma, la fase de testing siempre sera la que se comprime.
Puntos Clave
- Waterfall es un modelo SDLC secuencial donde cada fase debe completarse antes de la siguiente
- Sus seis fases son: Requisitos, Diseno, Implementacion, Testing, Despliegue, Mantenimiento
- El testing se concentra en una fase dedicada despues de la implementacion — la mayor debilidad para QA
- Waterfall sobresale en industrias reguladas, contratos de precio fijo y proyectos con requisitos estables
- La fase de testing es rutinariamente comprimida cuando el desarrollo se atrasa
- A pesar de sus limitaciones, los principios de Waterfall siguen siendo valiosos incluso en entornos Agile