SDLC vs STLC: Comprendiendo Procesos de Desarrollo y Testing

Entender el Ciclo de Vida de Desarrollo de Software (SDLC) y el Ciclo de Vida de Testing de Software (STLC) es competencia fundamental para especialistas QA. Saber cómo funcionan los procesos de creación de software, en qué etapas comienza el testing y cómo diferentes metodologías afectan el trabajo del equipo es críticamente importante para trabajo efectivo. En esta guía completa, examinaremos ambos ciclos, su relación y aplicación en varias metodologías de desarrollo.

Qué es SDLC (Software Development Life Cycle)

SDLC (Software Development Life Cycle) es un proceso estructurado de desarrollo de software que describe etapas de creación de software desde concepto hasta finalización de soporte.

Por Qué se Necesita SDLC

1. Estructura — comprensión clara de qué hacer en cada etapa
2. Predictibilidad — capacidad de planificar plazos y recursos
3. Calidad — mecanismos integrados de control de calidad en cada etapa
4. Mitigación de riesgos — identificación temprana de problemas
5. Eficiencia — optimización de procesos y minimización de retrabajos
6. Comunicación — lenguaje común para todo el equipo

Etapas Clásicas de SDLC

Independientemente de la metodología, SDLC típicamente incluye las siguientes fases (aunque nombres y orden pueden variar):

1. Planning (Planificación)

Objetivo: Definir alcance del proyecto, recursos, plazos y presupuesto.

Actividades principales:

• Definición de objetivos de negocio y requisitos
• Estudio de viabilidad
• Análisis de riesgos
• Formación de equipo
• Creación de project charter
• Estimación de costo y plazos

Artefactos de salida:

• Plan de proyecto
• Documento de asignación de recursos
• Reporte de evaluación de riesgos
• Estimación de presupuesto

Rol QA:

• Participación en evaluación de riesgos
• Planificación de recursos de testing
• Estimación de esfuerzo de testing
• Input sobre requisitos de calidad

2. Requirements Analysis (Análisis de Requisitos)

Objetivo: Comprensión detallada de qué necesita desarrollarse.

Actividades principales:

• Recopilación de requisitos de negocio de stakeholders
• Documentación de requisitos funcionales
• Definición de requisitos no funcionales (rendimiento, seguridad, usabilidad)
• Creación de casos de uso e historias de usuario
• Priorización de requisitos
• Aprobación de stakeholders

Artefactos de salida:

• Business Requirements Document (BRD)
• Software Requirements Specification (SRS)
• Casos de uso
• Historias de usuario
• Criterios de aceptación

Rol QA:

• Revisión de requisitos para completitud, claridad, testabilidad
• Participación en requirement walkthrough
• Creación de requirement traceability matrix
• Definición de criterios de aceptación
• Identificación temprana de ambigüedad y contradicciones

Preguntas QA en esta etapa:

• ¿Son requisitos testeables?
• ¿Están todos los edge cases cubiertos?
• ¿Hay contradicciones entre requisitos?
• ¿Están definidos requisitos no funcionales?

3. Design (Diseño)

Objetivo: Definir arquitectura del sistema y diseño de componentes.

Actividades principales:

• Diseño de alto nivel (arquitectura del sistema)
• Diseño de bajo nivel (diseño detallado de componentes)
• Diseño de base de datos
• Diseño UI/UX
• Diseño de API
• Selección de stack tecnológico
• Revisión de diseño

Artefactos de salida:

• High-Level Design (HLD) document
• Low-Level Design (LLD) document
• Esquema de base de datos
• Especificaciones de API
• Mockups y wireframes UI
• Diagramas de arquitectura

Rol QA:

• Revisión de documentación de diseño
• Verificación de testabilidad de arquitectura
• Planificación de estrategia de testing
• Diseño de entorno de testing
• Identificación de requisitos de datos de prueba
• Inicio de creación de plan de testing

Importante: En etapa de diseño, QA puede identificar problemas que serán difíciles de testear y sugerir cambios.

4. Implementation / Development (Implementación / Desarrollo)

Objetivo: Escribir código según diseño.

Actividades principales:

• Escritura de código
• Unit testing
• Code review
• Control de versiones (git commits)
• Integración de componentes
• Integración continua

Artefactos de salida:

• Código fuente
• Unit tests
• Build artifacts
• Documentación técnica
• Notas de code review

Rol QA:

• Preparación de datos de prueba
• Creación de casos de prueba y escenarios
• Configuración de entornos de testing
• Desarrollo de pruebas automatizadas (si existe automatización)
• Smoke tests tempranos en builds dev
• Participación en code reviews (en algunos equipos)

5. Testing (Pruebas)

Objetivo: Identificación de defectos y verificación de cumplimiento de requisitos.

Actividades principales:

• Ejecución de varios tipos de testing:
  • Functional testing
  • Integration testing
  • System testing
  • Regression testing
  • Performance testing
  • Security (como se discute en Bug Anatomy: From Discovery to Resolution) testing
  • Usability testing
• Reporte y seguimiento de bugs
• Retesting y regresión
• Reporte de testing

Artefactos de salida:

• Reportes de ejecución de pruebas
• Reportes de bugs
• Métricas de testing
• Traceability matrix
• Sign-off para transición a deployment

Rol QA:

• Fase principal para QA
• Ejecución de todos los tipos de testing
• Reporte y seguimiento de bugs
• Coordinación con desarrolladores
• Provisión de métricas de calidad

6. Deployment / Release (Despliegue / Lanzamiento)

Objetivo: Entrega de producto a usuarios.

Actividades principales:

• Preparación de entorno de producción
• Final smoke testing
• Despliegue en producción
• Monitoreo
• Preparación de plan de rollback
• Documentación de usuario

Artefactos de salida:

• Producto lanzado
• Notas de release
• Documentación de usuario
• Checklist de despliegue
• Procedimiento de rollback

Rol QA:

• Final smoke testing antes de release
• Sanity testing después de deployment
• Verificación de rutas críticas en producción
• Monitoreo de problemas de producción
• Participación en decisión go/no-go

7. Maintenance (Mantenimiento)

Objetivo: Corrección de bugs, actualizaciones, mejoras.

Actividades principales:

• Corrección de bugs
• Optimización de rendimiento
• Parches de seguridad
• Mejoras de características
• Soporte de usuario
• Monitoreo y analytics

Artefactos de salida:

• Hotfixes
• Patch releases
• Documentación actualizada
• Reportes de rendimiento

Rol QA:

• Testing de hotfixes y patches
• Regression testing
• Monitoreo de problemas reportados por usuarios
• Análisis de métricas de producción
• Mejora continua de procesos de testing

Qué es STLC (Software Testing Life Cycle)

STLC (Software Testing Life Cycle) es una secuencia de pasos realizados en proceso de testing de software. STLC es un subconjunto de SDLC y se enfoca exclusivamente en testing.

STLC vs SDLC: Cuál es la Diferencia

Importante: STLC no comienza después de completar SDLC. Testing está integrado en todas las fases de SDLC.

Fases STLC

Para una comprensión completa de cómo el testing se integra en diferentes etapas, consulte nuestra guía sobre niveles de testing.

Fase 1: Requirement Analysis (Análisis de Requisitos)

Objetivo: Entender qué será testeado.

Actividades:

• Estudio de requisitos (BRD, SRS, historias de usuario)
• Identificación de requisitos testeables
• Reuniones de revisión de requisitos
• Definición de alcance de testing
• Identificación de diferentes tipos de testing
• Preparación de Requirement Traceability Matrix (RTM)

Entry Criteria:

• Requisitos documentados
• Acceso a documentos de requisitos
• Stakeholders disponibles para clarificaciones

Exit Criteria:

• RTM creada
• Viabilidad de automatización determinada
• Todas las preguntas sobre requisitos resueltas

Entregables:

• RTM (Requirement Traceability Matrix)
• Reporte de viabilidad de automatización
• Lista de preguntas/clarificaciones

Fase 2: Test Planning (Planificación de Testing)

Objetivo: Definir estrategia y recursos para testing.

Actividades:

• Preparación de Test Plan
• Definición de test strategy
• Estimación de esfuerzo
• Selección de herramientas de testing
• Definición de roles y responsabilidades
• Evaluación de riesgos para testing
• Planificación de entorno de testing

Entry Criteria:

• Requisitos analizados
• RTM lista

Exit Criteria:

• Test Plan aprobado
• Estimación de esfuerzo completada
• Recursos asignados

Entregables:

• Documento de Test Plan
• Documento de Test Strategy
• Documento de estimación de esfuerzo

Test Plan incluye:

• Alcance de testing (qué testear, qué no testear)
• Enfoque de testing (tipos de testing)
• Roles y responsabilidades
• Cronograma de testing
• Criterios de entry/exit para cada fase
• Plan de mitigación de riesgos
• Entregables de testing

Fase 3: Test Case Development (Desarrollo de Casos de Prueba)

Objetivo: Crear casos de prueba detallados y datos de prueba.

Actividades:

• Escritura de casos de prueba
• Creación de scripts de prueba (para automatización)
• Revisión de casos de prueba
• Creación/adquisición de datos de prueba
• Priorización de casos de prueba
• Creación de trazabilidad entre requisitos y casos de prueba

Entry Criteria:

• Test plan aprobado
• Requisitos disponibles y estables
• RTM creada

Exit Criteria:

• Todos los casos de prueba escritos y revisados
• Datos de prueba preparados
• Traceability matrix actualizada

Entregables:

• Casos de prueba
• Scripts de prueba (para automatización)
• Datos de prueba
• RTM actualizada

Buen caso de prueba incluye:

• Test case ID
• Descripción de prueba
• Precondiciones
• Pasos de prueba
• Datos de prueba
• Resultado esperado
• Resultado real (se llena durante ejecución)
• Estado
• Prioridad

Fase 4: Test Environment Setup (Configuración de Entorno de Prueba)

Objetivo: Preparar entorno para ejecución de pruebas.

Actividades:

• Configuración de entorno de prueba (hardware, software, red)
• Preparación de datos de prueba en base de datos
• Configuración de herramientas de testing
• Smoke test del entorno
• Adquisición de builds de prueba

Entry Criteria:

• Test plan listo
• Documento de diseño de entorno de prueba listo

Exit Criteria:

• Entorno de prueba listo
• Smoke test pasado
• Datos de prueba cargados

Entregables:

• Entorno de prueba listo para uso
• Resultados de smoke test

Fase 5: Test Execution (Ejecución de Testing)

Objetivo: Ejecutar casos de prueba y encontrar defectos.

Actividades:

• Ejecución de casos de prueba según plan
• Comparación de resultados reales con esperados
• Logging de defectos para pruebas fallidas
• Retesting de defectos después de corrección
• Regression testing
• Actualización de estado de casos de prueba
• Seguimiento de ejecución de pruebas

Entry Criteria:

• Entorno de prueba listo
• Casos de prueba listos
• Build listo para testing
• Smoke test pasado

Exit Criteria:

• Todos los casos de prueba planificados ejecutados
• Bugs críticos y altos corregidos y retesteados
• Regression testing completado
• Exit criteria del test plan cumplidos

Entregables:

• Reportes de ejecución de pruebas
• Reportes de defectos
• Casos de prueba actualizados (si es necesario)
• Logs de prueba

Tipos de testing en esta fase:

• Smoke testing
• Functional testing
• Integration testing
• System testing
• Regression testing
• Exploratory testing
• Non-functional testing (performance, security (como se discute en Continuous Testing in DevOps: Quality Gates and CI/CD Integration), usability)

Fase 6: Test Cycle Closure (Cierre de Ciclo de Testing)

Objetivo: Evaluar completitud de testing y recopilar aprendizajes.

Actividades:

• Recopilación de artefactos de prueba
• Análisis de métricas de prueba
• Preparación de reporte resumen de prueba
• Reunión de lecciones aprendidas
• Identificación de mejores prácticas
• Archivo de artefactos de prueba

Entry Criteria:

• Ejecución de pruebas completada
• Todos los bugs críticos cerrados
• Regression testing completado

Exit Criteria:

• Reporte de cierre de pruebas listo
• Sign-off de stakeholders recibido

Entregables:

• Reporte de cierre de pruebas
• Métricas de prueba
• Documento de lecciones aprendidas
• Documentación de mejores prácticas

Métricas de Prueba incluyen:

• Total de casos de prueba vs. ejecutados
• Porcentaje Pass/Fail
• Densidad de defectos
• Fuga de defectos
• Cobertura de pruebas
• Velocidad de ejecución de pruebas

Metodologías de Desarrollo y Lugar del Testing

Waterfall Model (Modelo Cascada)

Descripción: Modelo secuencial donde cada fase comienza solo después de que la anterior se complete.

Fases: Requirements → Design → Implementation → Testing → Deployment → Maintenance

Características:

• Secuencia estricta de fases
• No se puede volver a fase anterior
• Testing — fase separada después de desarrollo
• Documentación extensa
• Requisitos fijos

Lugar del testing en Waterfall:

• Testing — fase separada, tardía
• QA involucrado en revisión de requisitos, pero trabajo principal después de coding
• Ciclo de prueba largo
• Alto riesgo de encontrar bugs críticos en etapas tardías

Pros para QA:

• Requisitos claros
• Documentación completa
• Tiempo suficiente para testing minucioso
• Fácil planificación de recursos

Contras para QA:

• Descubrimiento tardío de defectos (costoso de corregir)
• Poca flexibilidad para cambios
• Si se perdió bug, rollback costoso
• Ciclo de feedback largo

Cuándo se usa:

• Proyectos con requisitos claramente definidos, estables
• Industrias reguladas (medicina, finanzas)
• Proyectos con alcance y timeline fijos

V-Model (Modelo V - Verificación y Validación)

Descripción: Extensión de Waterfall donde para cada fase de desarrollo existe fase de testing correspondiente.

Estructura:

Requirements ←→ Acceptance Testing
System Design ←→ System Testing
Architecture Design ←→ Integration Testing
Module Design ←→ Unit Testing
      ↓
  Implementation

Características:

• Testing planificado paralelo a desarrollo
• Para cada etapa de desarrollo — etapa de testing correspondiente
• Verificación (¿Estamos construyendo el producto correctamente?) y Validación (¿Estamos construyendo el producto correcto?)
• Artefactos de prueba creados temprano

Lugar del testing en V-Model:

• QA involucrado desde el inicio
• Test planning comienza en fase de requisitos
• Test case design paralelo a fase de diseño
• Test execution después de implementation

Mapeo de fases:

• Requirements Analysis → Acceptance Test Planning
  • User Acceptance Tests (UAT)
  • Verificación de requisitos de negocio
• System Design → System Test Planning
  • Testing end-to-end
  • Testing funcional y no funcional
• High-Level Design → Integration Test Planning
  • Testing de interacciones de módulos
  • Testing de API
• Low-Level Design → Unit Test Planning
  • Testing de componentes individuales
  • Testing dirigido por desarrollador

Pros para QA:

• Involucramiento temprano de QA
• Defectos encontrados más temprano (más barato corregir)
• Correlación clara entre desarrollo y testing
• Mejor cobertura de pruebas

Contras para QA:

• Sigue siendo modelo inflexible
• Difícil adaptarse a cambios
• Requiere documentación extensa

Cuándo se usa:

• Sistemas críticos de seguridad (automotriz, aeroespacial, médico)
• Proyectos con requisitos claros, estables
• Industrias reguladas

Agile Methodology (Metodología Ágil)

Descripción: Enfoque iterativo e incremental donde desarrollo se realiza en ciclos cortos (sprints).

Principios Agile:

• Individuos e interacciones sobre procesos y herramientas
• Software funcional sobre documentación exhaustiva
• Colaboración con cliente sobre negociación de contrato
• Respuesta al cambio sobre seguir un plan

Características:

• Iteraciones cortas (típicamente 1-4 semanas)
• Feedback continuo
• Equipos auto-organizados
• Colaboración cercana
• Adaptación a cambios

Lugar del testing en Agile:

• Testing — proceso continuo dentro de cada sprint
• QA — miembro completo del equipo, no fase separada
• Testers trabajan paralelo a desarrolladores
• Continuous testing y continuous integration

Agile Testing Quadrants (Brian Marick):

Business-Facing                     Technology-Facing

Q2: Functional Tests         |     Q1: Unit Tests
- Manual/Exploratory         |     - Automated
- User Stories               |     - Component Tests
- Examples/Scenarios         |     - API Tests
Support Programming          |     Support Programming
--------------------------------|---------------------------
Q3: Usability Tests         |     Q4: Performance Tests
- Manual                     |     - Automated
- User Acceptance           |     - Load Tests
- A/B Testing               |     - Security Tests
Critique Product            |     Critique Product

QA en Agile Sprint:

Día 1-2 (Sprint Planning):

• Participación en planning
• Clarificación de requisitos
• Estimación de esfuerzo de testing
• Definición de criterios de aceptación
• Planificación de enfoque de testing

Día 3-8 (Development + Testing):

• Testing de historias de usuario listas
• Exploratory testing
• Regression testing
• Reporte de bugs y retesting
• Creación/actualización de pruebas de automatización
• Comunicación constante con devs

Día 9-10 (Sprint End):

• Regresión final
• Participación en demo
• Participación en retrospective
• Preparación de métricas de prueba
• Planificación para siguiente sprint

Pros para QA:

• Testing temprano y continuo
• Ciclo de feedback rápido
• Defectos corregidos en mismo sprint
• Colaboración cercana con equipo
• Flexibilidad y adaptabilidad

Contras para QA:

• Menos documentación (puede ser poco claro)
• Timelines ajustados (presión)
• Debe ser multitarea (testing + automatización + comunicación)
• Regresión puede acumularse
• Requiere alto nivel de automatización

Frameworks Agile:

Scrum:

• Sprints (típicamente 2 semanas)
• Roles: Product Owner, Scrum Master, Development Team (incluyendo QA)
• Ceremonias: Sprint Planning, Daily Standup, Sprint Review, Retrospective
• Artefactos: Product Backlog, Sprint Backlog, Increment

Kanban:

• Flujo continuo (sin sprints)
• Límites de Work In Progress (WIP)
• Tablero visual
• Sistema pull-based

Cuándo se usa Agile:

• Startups y entornos dinámicos
• Proyectos con requisitos cambiantes
• Productos que requieren time-to-market rápido
• Aplicaciones web, aplicaciones móviles

DevOps y Continuous Testing

DevOps une Development y Operations para acelerar delivery.

Prácticas clave:

• Continuous Integration (CI)
• Continuous Delivery (CD)
• Infrastructure as Code
• Monitoring and Logging
• Cultura de colaboración

Lugar del testing en DevOps:

Shift-Left Testing — testing se desplaza a la izquierda (más temprano en SDLC):

• Unit tests escritos por desarrolladores
• API tests automatizados
• Integration tests en pipeline CI/CD
• Static code analysis

CI/CD Pipeline con testing:

Code Commit → Build → Unit Tests → Integration Tests → Deploy to Staging →
Smoke Tests → Regression Tests → Deploy to Production → Monitoring

Automatización en DevOps:

• 70-80% de cobertura de pruebas automatización
• Feedback rápido (minutos, no horas)
• Tests se ejecutan en cada commit
• Tests fallidos bloquean deployment

Rol QA en DevOps:

• Creación y mantenimiento de pruebas automatizadas
• Configuración de pipelines CI/CD para testing
• Monitoreo de producción (observabilidad)
• Performance y security testing
• Exploratory testing para nueva funcionalidad

Elección de Metodología: Tabla Comparativa

Mejores Prácticas QA en Diferentes Metodologías

Para cualquier metodología:

1. Involucramiento temprano — participar en análisis de requisitos
2. Revisión de requisitos — verificar testabilidad de requisitos
3. Planificación de testing — planificar con anticipación
4. Testing basado en riesgos — enfocarse en áreas críticas
5. Comunicación clara — comunicar claramente estado y riesgos
6. Seguimiento de métricas — rastrear métricas de calidad
7. Aprendizaje continuo — aprender de errores

Específico para Waterfall/V-Model:

• Invertir tiempo en documentación detallada
• Planificación de cobertura de pruebas completa
• Análisis minucioso de requisitos
• Sign-offs formales en cada etapa

Específico para Agile/DevOps:

• Automation first — automatizar todo lo posible
• Continuous testing — testear constantemente, no al final
• Shift-left — encontrar bugs tan temprano como sea posible
• Collaboration — trabajar cercanamente con devs
• Exploratory testing — no confiar solo en scripted tests
• Fast feedback — proporcionar feedback rápido

Conclusión

Entender SDLC y STLC, así como varias metodologías de desarrollo, no es solo teoría. Es conocimiento práctico que define cómo trabajarás cada día:

Conclusiones Clave:

1. SDLC y STLC están interconectados pero no son lo mismo. STLC es el ciclo de testing dentro de SDLC que debe estar integrado en todas las fases de desarrollo, no ser una etapa separada al final.

2. Metodología define rol QA. En Waterfall testeas al final, en Agile — constantemente, en DevOps — automatizas y monitoreas producción.

3. No hay enfoque universal. Waterfall puede ser elección correcta para industrias reguladas, Agile — para startups, V-Model — para sistemas críticos.

4. Involucramiento temprano de QA críticamente importante independientemente de metodología. Cuanto antes encuentres defectos, más barata su corrección.

5. Automatización no es opcional en mundo moderno, especialmente en Agile y DevOps. Testing manual no escala.

6. Adaptación es habilidad clave. Metodologías evolucionan, enfoques híbridos (Water-Scrum-Fall, por ejemplo) existen. Importante entender principios y adaptarlos al contexto del equipo.

7. Testing no es fase, es mentalidad. Calidad es responsabilidad de todo el equipo, no solo del departamento QA.

Especialista QA exitoso no solo conoce teoría de SDLC y STLC sino puede aplicar este conocimiento en trabajo real, adaptándose a metodología del equipo y mejorando constantemente procesos de testing.

Próximos pasos:

• Estudiar 7 principios de testing de ISTQB para comprensión profunda de fundamentos
• Identificar qué metodología usa tu equipo
• Evaluar dónde testing en tu SDLC puede comenzar más temprano
• Explorar oportunidades de automatización en tu proyecto