Cuando hablamos de desarrollo de software, es común que la palabra “pruebas” evoque la imagen de una etapa aislada, ubicada al final del proceso: algo que ocurre después de que el código ya ha sido escrito. Aunque esta visión todavía está presente en muchas organizaciones, cada vez está más alejada de la realidad de los equipos maduros de ingeniería de calidad.
El STLC (Software Testing Life Cycle), o Ciclo de Vida de Pruebas de Software, es el conjunto estructurado de fases que organiza y orienta todas las actividades de prueba a lo largo del desarrollo. Más que una secuencia de etapas, el STLC representa un cambio de perspectiva: la calidad no se verifica al final, sino que se construye desde el inicio.
SDLC y STLC: Dos Ciclos, Un Objetivo
Para comprender el STLC, es útil situarlo dentro de un contexto más amplio: el SDLC (Software Development Life Cycle), o Ciclo de Vida del Desarrollo de Software.
El SDLC organiza el proceso de creación de software en fases como:
- Planificación
- Análisis de Requisitos
- Diseño
- Desarrollo (Codificación)
- Pruebas
- Implementación
- Mantenimiento
En este modelo tradicional, las pruebas aparecen como una fase específica: una etapa entre el desarrollo y la implementación. El problema de este enfoque es que los defectos detectados tarde son significativamente más costosos y difíciles de corregir.
El STLC responde a este problema al estructurar las actividades de prueba de forma paralela e integrada al SDLC. Mientras el SDLC define qué se construirá y cómo, el STLC define cómo se garantizará la calidad en cada etapa de ese proceso.
La Correspondencia entre Desarrollo y Pruebas
Esta integración no es solo una buena práctica: es un principio formalizado. El ISTQB Foundation Level Syllabus (sección 2.1) establece explícitamente que para cada actividad de desarrollo existe una actividad de prueba correspondiente, de modo que todas las etapas del desarrollo estén sujetas al control de calidad. Además, el syllabus determina que el análisis y diseño de pruebas para un determinado nivel deben comenzar durante la fase de desarrollo correspondiente, y no después de ella.
En la práctica, esto significa que QA no espera a que el código esté terminado para comenzar a trabajar. Mientras se definen los requisitos, las pruebas ya se están planificando. Mientras se diseña el sistema, se elaboran los casos de prueba. Mientras se escribe el código, se prepara el entorno de pruebas. La siguiente tabla ilustra esta correspondencia en el contexto del modelo secuencial clásico:
| Fase del SDLC | Actividad de prueba correspondiente |
|---|---|
| Análisis de Requisitos | Análisis de requisitos comprobables; identificación de condiciones de prueba |
| Diseño | Planificación de pruebas; definición de la estrategia |
| Desarrollo (Codificación) | Diseño de casos de prueba; configuración del entorno de pruebas |
| Pruebas | Ejecución de pruebas; reporte de defectos |
| Implementación | Cierre del ciclo; pruebas de sanidad en producción |
Vale la pena destacar que el ISTQB reconoce explícitamente que esta correspondencia varía según el modelo de ciclo de vida adoptado. En modelos iterativos y ágiles, las fases se superponen y se comprimen en ciclos cortos, pero el principio de correspondencia se mantiene: ninguna entrega de desarrollo debería ocurrir sin una actividad de calidad asociada.
Las Fases del STLC
A diferencia de lo que algunos materiales pueden sugerir, no existe una definición formal ni estandarizada del STLC: ningún organismo como ISO, IEEE o ISTQB establece un modelo oficial con fases fijas y obligatorias. Lo que se encuentra en la literatura técnica y en las guías de la industria es una convergencia en torno a seis fases, ampliamente adoptadas por equipos de calidad alrededor del mundo, aunque con variaciones en nomenclatura, cantidad de etapas y alcance según el contexto, la metodología y el nivel de madurez de cada organización.
En este artículo, adopto un modelo de siete fases (6 + 1) como referencia, no porque sea “el modelo correcto”, sino porque representa una estructura coherente, aplicable y lo suficientemente amplia para fines educativos y profesionales. La séptima fase — el seguimiento posterior a la liberación — es una adición deliberada al modelo más común encontrado en la literatura, motivada por la realidad de equipos que operan con entrega continua y necesitan extender la cobertura de calidad más allá de la implementación.
Cada fase se describe con sus actividades típicas y criterios de salida, los cuales deben adaptarse a la realidad de cada equipo.
1. Análisis de Requisitos
Comprensión de los requisitos e identificación de condiciones comprobables
La primera fase del STLC comienza donde muchos aún creen que las pruebas no tienen lugar: en la planificación y el análisis de requisitos. Aquí es donde el profesional de calidad (QA) realiza una de las contribuciones más valiosas de todo el ciclo.
Al participar en las reuniones iniciales de una iniciativa o proyecto — el llamado flujo upstream —, QA tiene la oportunidad de:
- Identificar qué puede y debe probarse, mapeando condiciones comprobables directamente a partir de los requisitos;
- Aportar su experiencia práctica, anticipando situaciones que históricamente han generado fallas, señalando ambigüedades en los requisitos y promoviendo discusiones que mejoren la calidad de la especificación antes de escribir una sola línea de código.
Esta participación temprana de QA es la base del concepto de shift-left testing: mover las actividades de calidad hacia la izquierda en la línea de tiempo del proyecto, logrando una detección de problemas más temprana, económica y eficaz.
Criterios de salida de esta fase: lista documentada de requisitos comprobables; dudas e inconsistencias identificadas y enviadas para resolución.
2. Planificación de Pruebas
Definición de la estrategia general de pruebas
Con los requisitos analizados, la segunda fase estructura la estrategia que guiará todas las demás actividades. El principal artefacto generado aquí es el Plan de Pruebas: un documento que formaliza las decisiones clave sobre cómo se ejecutarán las pruebas.
Un buen plan de pruebas contempla, entre otros aspectos:
- Alcance: qué se probará y qué queda fuera del alcance;
- Estrategias: qué tipos de pruebas se aplicarán (funcionales, regresivas, automatizadas, manuales, de rendimiento, entre otras);
- Responsabilidades: quién ejecutará las pruebas, incluyendo posible participación de otros equipos;
- Entornos: en qué ambientes se realizarán las pruebas (UAT, staging, sandbox);
- Cronograma: cuándo comienzan las pruebas y cuándo deben finalizar.
El plan de pruebas no necesita ser un documento extenso y burocrático. En contextos ágiles, puede ser liviano, actualizado continuamente e integrado a herramientas de gestión del equipo, como un campo descriptivo dentro de una suite de pruebas en una plataforma ALM (Application Lifecycle Management).
Criterios de salida de esta fase: plan aprobado por las partes interesadas; entornos definidos; cronograma acordado.
3. Diseño de Casos de Prueba
Desarrollo de casos de prueba y escenarios para cubrir requisitos
La tercera fase transforma los requisitos en casos de prueba concretos: los guiones que guiarán la verificación del comportamiento del sistema.
Un caso de prueba describe, de forma estructurada, las condiciones de entrada, las acciones a realizar y los resultados esperados para cada escenario de verificación. Su elaboración exige conocimiento técnico y comprensión del negocio: un buen caso cubre el escenario esperado (camino feliz), variaciones y escenarios de excepción.
Los casos de prueba pueden escribirse en diferentes formatos:
- Lenguaje natural (paso a paso): más accesible para equipos multidisciplinarios, describe cada acción del usuario y el resultado esperado secuencialmente;
- Lenguaje Gherkin (BDD): orientado al comportamiento, utiliza la estructura Given / When / Then para que negocio y tecnología compartan el mismo vocabulario.
Además de su creación, esta fase incluye la revisión de casos de prueba, un paso muchas veces descuidado, pero esencial para asegurar cobertura adecuada y eliminar redundancias.
Criterios de salida de esta fase: casos documentados, revisados y organizados en suites; cobertura de requisitos verificada.
4. Configuración del Entorno de Pruebas
Preparación de la infraestructura donde se ejecutarán las pruebas
Antes de ejecutar cualquier prueba, es necesario garantizar que el entorno esté adecuadamente preparado. Esta fase se ocupa de la instalación, configuración y validación de los ambientes de prueba.
Idealmente, el entorno de pruebas debe reflejar producción en términos de sistema operativo, versiones de software, volumen de datos y configuraciones de red. La diferencia entre ambos es una de las principales causas de defectos detectados recién en producción.
Las actividades típicas incluyen:
- Aprovisionamiento o actualización del entorno (máquinas, contenedores, servidores, bases de datos);
- Configuración de datos de prueba adecuados y representativos;
- Validación de que el entorno funciona y es accesible para el equipo de pruebas;
- Configuración de herramientas de prueba (frameworks, automatización, recolectores de evidencias).
En organizaciones con prácticas DevOps maduras, gran parte de esto está automatizado, con entornos creados y destruidos bajo demanda dentro de pipelines CI/CD.
Criterios de salida de esta fase: entorno validado y documentado; herramientas configuradas y operativas.
5. Ejecución de Pruebas
Ejecución de casos de prueba y registro de resultados
En esta fase se ejecutan realmente los casos planificados. Para cada caso, QA sigue el guion definido, registra el resultado obtenido y lo compara con el esperado.
Cuando el comportamiento difiere de lo esperado, existe una falla, que debe investigarse para determinar si se trata de un defecto (bug), un problema del entorno, una inconsistencia en la especificación o un caso de prueba inadecuado.
Los defectos identificados deben documentarse individualmente y con detalle, incluyendo:
- Descripción clara del comportamiento observado vs. esperado;
- Pasos para reproducir;
- Evidencias (capturas de pantalla, logs, videos);
- Severidad y prioridad;
- Versión del sistema donde se encontró.
Esta documentación es fundamental para que los desarrolladores investiguen y corrijan con eficiencia, y para que QA pueda verificar la corrección posteriormente (retesting).
Paralelamente, los resultados alimentan reportes y tableros que ofrecen visibilidad en tiempo real del progreso y la calidad de la entrega.
Criterios de salida de esta fase: todos los casos planificados ejecutados; defectos documentados y asignados; reporte disponible.
6. Cierre del Ciclo de Pruebas
Consolidación de resultados y análisis de actividades
La sexta fase formaliza el cierre del ciclo en un entorno controlado. Más que un informe final, es una oportunidad de aprendizaje organizacional.
Las actividades incluyen:
- Análisis de resultados: cuántos casos fueron ejecutados, aprobados, fallidos o bloqueados; estado de los defectos encontrados;
- Evaluación de cobertura: ¿los requisitos fueron adecuadamente cubiertos?
- Lecciones aprendidas: ¿qué funcionó bien? ¿qué puede mejorarse en el siguiente ciclo?
- Archivo de artefactos: casos, reportes y evidencias organizados para consultas futuras.
En muchas organizaciones, esta fase también incluye la presentación de resultados a las partes interesadas, especialmente cuando se identificaron riesgos relevantes o la cobertura quedó por debajo de lo planificado.
Criterios de salida de esta fase: informe final publicado; lecciones aprendidas registradas; métricas consolidadas.
7. Más allá del STLC: Seguimiento Post-Liberación
Verificación en producción y monitoreo continuo
En equipos con prácticas DevOps y entrega continua, la responsabilidad de QA no termina con la implementación. Después de la liberación en producción, esta fase asegura que la entrega funcione como se espera en el entorno real, el más impredecible de todos.
Las actividades típicas incluyen:
- Ejecución de pruebas no invasivas en producción (smoke tests o pruebas de sanidad) para confirmar que las funciones críticas operan correctamente;
- Seguimiento de pruebas automatizadas de regresión para asegurar que la nueva entrega no introdujo fallas en funciones ya validadas;
- Monitoreo de indicadores de calidad en producción (tasas de error, logs de excepciones, alertas de rendimiento) como señal complementaria.
La inclusión de esta fase refleja una visión de calidad más amplia: producción es el juez final, y QA debe tener visibilidad de lo que ocurre allí después de cada entrega.
Criterios de salida de esta fase: smoke tests ejecutados y aprobados; ausencia de regresiones críticas confirmada; evidencias de estabilidad registradas.
Control, Aseguramiento y Gestión de la Calidad en el STLC
El STLC opera en tres dimensiones complementarias:
- Control de Calidad (QC): actividades de verificación para encontrar defectos mediante pruebas;
- Aseguramiento de Calidad (QA): actividades preventivas para garantizar procesos adecuados;
- Gestión de Calidad: planificación, monitoreo y mejora continua de procesos.
Los profesionales de QA que participan en todas las fases del STLC se mueven naturalmente entre estas tres dimensiones, y esa amplitud es lo que diferencia a un equipo maduro de uno que simplemente “prueba al final”.
Conclusión
El STLC representa la organización sistemática de las actividades de prueba a lo largo de todo el ciclo de vida del desarrollo. Al estructurar la calidad en fases con entradas, actividades y criterios de salida definidos, e integrar QA desde el análisis de requisitos, el STLC transforma la calidad de un evento puntual en un proceso continuo.
Comprender y aplicar el STLC es un paso fundamental para equipos que buscan no solo encontrar defectos, sino prevenirlos, entregando mejor software con mayor previsibilidad y menos retrabajo.
