¿Qué es el Ciclo de Vida del Testing de Software?
El Software Testing Life Cycle (STLC) es un enfoque sistemático para el testing que define los pasos y actividades realizadas durante cada fase. Así como el desarrollo sigue el SDLC, el testing sigue el STLC.
El STLC asegura que el testing sea organizado, exhaustivo y rastreable. Transforma el testing de una actividad ad-hoc en un proceso estructurado con entradas, salidas y criterios de calidad claros.
Las Seis Fases del STLC
Requisitos] --> TP[2. Planificación
de Tests] TP --> TCD[3. Diseño de
Casos de Prueba] TCD --> ES[4. Configuración
de Entorno] ES --> TE[5. Ejecución
de Tests] TE --> TC[6. Cierre
de Tests] style RA fill:#4CAF50,color:#fff style TP fill:#2196F3,color:#fff style TCD fill:#FF9800,color:#fff style ES fill:#9C27B0,color:#fff style TE fill:#F44336,color:#fff style TC fill:#795548,color:#fff
Fase 1: Análisis de Requisitos
Objetivo: Entender qué necesita probarse y determinar la testeabilidad.
Criterios de entrada: Documento de requisitos disponible, stakeholders disponibles para clarificaciones.
Actividades:
- Revisar requisitos por completitud, claridad y testeabilidad
- Identificar tipos de testing requeridos (funcional, rendimiento, seguridad)
- Determinar alcance del testing
- Identificar factibilidad de automatización
- Conducir sesiones Three Amigos para requisitos complejos
- Identificar brechas y ambigüedades en requisitos
Entregables:
- Matriz de Trazabilidad de Requisitos (RTM)
- Lista de requisitos testeables
- Reporte de factibilidad de automatización
- Lista de preguntas para stakeholders
Fase 2: Planificación de Tests
Objetivo: Definir la estrategia, alcance, esfuerzo y cronograma de testing.
Actividades:
- Definir estrategia de testing (manual vs. automatizado, tipos de testing)
- Estimar esfuerzo de testing (tiempo, personas, herramientas)
- Planificar requisitos de entorno de prueba
- Identificar herramientas necesarias
- Definir roles y responsabilidades
- Crear análisis de riesgos y plan de mitigación
- Definir criterios de entrada y salida
Entregables:
- Documento de Plan de Tests
- Documento de estimación de esfuerzo
- Documento de planificación de recursos
Fase 3: Diseño de Casos de Prueba
Objetivo: Crear casos de prueba detallados y datos de prueba.
Actividades:
- Escribir casos de prueba basados en requisitos
- Diseñar conjuntos de datos de prueba (positivos, negativos, valores límite)
- Crear scripts de tests automatizados
- Revisar y priorizar casos de prueba
- Mapear casos de prueba a requisitos en la RTM
Entregables:
- Casos de prueba (con pasos, resultados esperados, precondiciones)
- Conjuntos de datos de prueba
- Scripts de tests automatizados
- RTM actualizada
Fase 4: Configuración de Entorno
Objetivo: Preparar el entorno de prueba y verificar que esté listo.
Actividades:
- Configurar entorno de prueba (hardware, software, red)
- Instalar y configurar la aplicación bajo prueba
- Preparar datos de prueba en el entorno
- Configurar herramientas de testing
- Realizar smoke testing para verificar preparación
- Documentar configuración del entorno
Entregables: Entorno de prueba listo, documento de configuración, resultados de smoke test.
Nota: La configuración de entorno a menudo se ejecuta en paralelo con el Diseño de Casos de Prueba para ahorrar tiempo.
Fase 5: Ejecución de Tests
Objetivo: Ejecutar casos de prueba, registrar resultados y reportar defectos.
Actividades:
- Ejecutar casos de prueba (manual y automatizado)
- Comparar resultados reales con esperados
- Registrar defectos para casos fallidos
- Re-probar defectos corregidos
- Ejecutar testing de regresión
- Rastrear progreso de ejecución
- Actualizar estado en herramienta de gestión de tests
Entregables:
- Resultados de ejecución (pass/fail/blocked/skipped)
- Reportes de defectos
- Reportes de estado diarios/semanales
- RTM actualizada con resultados
Fase 6: Cierre de Tests
Objetivo: Evaluar completitud del testing y capturar lecciones aprendidas.
Actividades:
- Evaluar criterios de completitud vs. resultados reales
- Analizar métricas de testing (tasa de aprobación, densidad de defectos, cobertura)
- Documentar lecciones aprendidas
- Crear reporte resumen de tests
- Archivar artefactos de testing
Entregables:
- Reporte Resumen de Tests (Test Closure Report)
- Documento de lecciones aprendidas
- Reporte de métricas
- Artefactos archivados
STLC vs SDLC
| Fase SDLC | Fase STLC | Actividad QA |
|---|---|---|
| Requisitos | Análisis de Requisitos | Revisar requisitos, crear RTM |
| Diseño | Planificación de Tests | Crear estrategia y plan |
| Implementación | Diseño de Casos + Configuración de Entorno | Escribir tests, preparar entorno |
| Testing | Ejecución de Tests | Ejecutar tests, reportar defectos |
| Despliegue | Cierre de Tests | Resumir resultados, lecciones |
| Mantenimiento | Testing continuo | Regresión para parches |
La Matriz de Trazabilidad de Requisitos (RTM)
La RTM mapea cada requisito a sus casos de prueba correspondientes:
| ID Req | Requisito | IDs Casos de Prueba | Estado |
|---|---|---|---|
| REQ-001 | Usuario puede registrarse con email | TC-001, TC-002, TC-003 | Aprobado |
| REQ-002 | Usuario puede iniciar sesión | TC-004, TC-005 | Aprobado |
| REQ-003 | Usuario puede restablecer contraseña | TC-006, TC-007, TC-008 | 1 Fallido |
| REQ-004 | Admin puede exportar reportes | TC-009 | No Ejecutado |
Por qué importa la RTM:
- Asegura que ningún requisito quede sin probar
- Muestra cobertura de testing de un vistazo
- Rastrea estado de requisitos a través del testing
- Identifica brechas en cobertura
- Requerida por muchos estándares de calidad (ISO, CMMI)
Ejercicio: Crear Entregables STLC para un Proyecto
Eres QA lead para un nuevo feature de banca en línea: Pago de Facturas. El feature permite:
- Agregar proveedores (electricidad, agua, internet)
- Programar pagos únicos o recurrentes
- Ver historial de pagos
- Recibir notificaciones de pagos próximos y completados
Tu tarea:
- Análisis de Requisitos: Crear una RTM con al menos 6 requisitos e identificar 2 problemas de testeabilidad
- Planificación: Escribir un esquema breve de plan de tests
- Diseño de Casos: Escribir 3 casos de prueba detallados (positivo, negativo, límite)
- Ejecución: Dados estos resultados, determinar si se cumplen los criterios de salida
Pista
Para la RTM, piensa en requisitos funcionales y no funcionales. El pago de facturas involucra transacciones financieras — seguridad y precisión son críticas.
Solución de Ejemplo
1. RTM
| ID Req | Requisito | Casos de Prueba | Prioridad |
|---|---|---|---|
| BP-001 | Usuario puede agregar proveedor por nombre o número de cuenta | TC-001, TC-002, TC-003 | Alta |
| BP-002 | Usuario puede programar pago único | TC-004, TC-005, TC-006 | Alta |
| BP-003 | Usuario puede programar pago recurrente | TC-007, TC-008, TC-009, TC-010 | Alta |
| BP-004 | Usuario puede ver historial de pagos (últimos 12 meses) | TC-011, TC-012 | Media |
| BP-005 | Usuario recibe notificación 2 días antes del pago | TC-013, TC-014 | Media |
| BP-006 | Monto de pago no debe exceder saldo de cuenta | TC-015, TC-016, TC-017 | Crítica |
Problemas de testeabilidad:
- Pagos recurrentes requieren triggers basados en tiempo — necesario simular cambios de fecha
- Procesamiento de pagos involucra APIs de terceros — necesario mocks o sandboxes
2. Esquema de Plan de Tests
Alcance: Testing funcional de pago de facturas: agregar proveedor, programar pago, historial, notificaciones.
Tipos de testing: Funcional, seguridad, rendimiento, usabilidad, regresión.
Riesgos: Mock de gateway puede no reflejar comportamiento real; pagos recurrentes son time-dependent.
3. Casos de Prueba
TC-004: Programar pago único (Positivo)
- Precondición: Usuario logueado, proveedor “Electricidad” agregado, saldo $500
- Pasos: 1) Seleccionar proveedor 2) Ingresar monto $100 3) Seleccionar fecha: mañana 4) Clic “Programar Pago”
- Esperado: Pago programado, confirmación mostrada
TC-016: Pago excede saldo (Negativo)
- Precondición: Usuario logueado, saldo $50
- Pasos: 1) Seleccionar proveedor 2) Ingresar monto $100 3) Clic “Programar Pago”
- Esperado: Error “Fondos insuficientes. Tu saldo es $50.00”
TC-017: Pago igual al saldo exacto (Límite)
- Precondición: Usuario logueado, saldo $100.00
- Pasos: 1) Seleccionar proveedor 2) Ingresar monto $100.00 3) Clic “Programar Pago”
- Esperado: Pago programado exitosamente
4. Evaluación de Criterios de Salida
Resultados: 45/50 ejecutados, 1 bug crítico diferido, 2 bugs medios abiertos, 89% aprobados.
Recomendación: NO aprobar release. 1 bug crítico diferido es bloqueante para un feature financiero.
Errores Comunes del STLC
- Saltarse Análisis de Requisitos — lleva a tests que no cubren escenarios críticos
- Planificación incompleta — causa scope creep y deadlines no cumplidos
- Sin criterios de entrada/salida — fases comienzan por fecha, no por preparación
- Cierre de tests pobre — lecciones nunca aprendidas, mismos errores se repiten
Consejos Pro
Automatiza actualizaciones de RTM. Usa herramientas (TestRail, Zephyr, Xray) que vinculen automáticamente casos a requisitos.
Comienza configuración de entorno temprano. Problemas de entorno son la causa #1 de retrasos.
Haz criterios de salida medibles. “Testing completo” no es criterio. “95% ejecutado, cero defectos críticos abiertos” sí lo es.
Realiza cierre de tests incluso en agile. Mini-cierre al final de cada sprint, cierre completo al final del release.
Usa la RTM en reuniones con stakeholders. Cuando alguien pregunte “¿estamos listos?”, la RTM da una respuesta objetiva.