Entregar software sin defectos críticos no es cuestión de suerte, y el ciclo de vida del testing (STLC, por sus siglas en inglés) es el marco que convierte las pruebas en un proceso ordenado y repetible, en lugar de una revisión apresurada antes del lanzamiento.
En esta guía verás qué es el STLC, para qué sirve, cuáles son sus siete fases, cómo funcionan los criterios de entrada y salida, en qué se diferencia del SDLC y qué beneficios aporta a tu equipo. También veremos cómo se complementa con la evaluación de la experiencia real de las personas usuarias.
¿Qué es el ciclo de vida del testing de software?
El ciclo de vida del testing es un proceso sistemático, dividido en fases, que valida un software frente a sus requisitos e identifica defectos antes de que lleguen a las personas usuarias. Cada fase tiene objetivos, actividades y entregables propios, y se apoya en un conjunto de criterios que indican cuándo se puede empezar y cuándo se puede dar por terminada.
Conviene aclarar que el STLC no se reduce a ejecutar casos de prueba. Empieza mucho antes, con el análisis de los requisitos, y termina mucho después de la última ejecución, con un informe de cierre que resume lo que se probó, lo que se encontró y qué tan sólido quedó el producto.
Esa estructura es lo que lo distingue de probar “cuando haya tiempo”. Con un ciclo definido, el equipo sabe qué se prueba, con qué datos, en qué entorno y bajo qué condiciones se considera aceptable el resultado.
Además, el ciclo deja evidencia. Los planes, los casos y los informes permiten auditar el trabajo, repetirlo en la siguiente versión y aprender de lo que falló en la anterior.
¿Por qué es importante el ciclo de vida del testing?
La razón principal es económica: un defecto cuesta mucho más cuanto más tarde se descubre. Un error de requisitos detectado en la primera semana se corrige con una conversación, mientras que el mismo error en producción exige parches, soporte, reputación dañada y, a veces, compensaciones.
59.500 millones de USD
Costo anual estimado para la economía de Estados Unidos por una infraestructura de pruebas de software inadecuada, según el estudio pionero del NIST.
Fuente: NIST, Planning Report 02-3, 2002
El dato es antiguo, pero la lógica sigue vigente y las cifras recientes son todavía mayores. Aun así, no es el único argumento, porque el STLC aporta valor en varios frentes a la vez.
- Detecta defectos temprano, al integrar las pruebas durante todo el desarrollo y no solo al final.
- Protege la calidad: comprueba que el software funciona como se espera y cumple lo acordado.
- Reduce riesgos, porque la validación continua deja al descubierto fallos de fiabilidad y de seguridad antes de la salida.
- Alinea el producto con los objetivos del negocio y con lo que esperan los clientes y las partes interesadas, algo que un listado de pruebas aisladas no garantiza.
- Sostiene la integración y el despliegue continuos: en metodologías ágiles y DevOps, las pruebas continuas son lo que permite liberar versiones con frecuencia sin perder control.
2,41 billones de USD
Costo estimado de la mala calidad del software en Estados Unidos durante 2022, que incluye pérdidas por vulnerabilidades y deuda técnica acumulada.
Fuente: CISQ (Consortium for Information and Software Quality), 2022
Estas cifras explican por qué la calidad dejó de ser una tarea final del área técnica y pasó a ser una decisión de negocio. Un ciclo de pruebas disciplinado es la forma más directa de reducir esa exposición.
¿Cuáles son las 7 fases del ciclo de vida del testing?
El STLC se compone de siete fases, cada una con objetivos y entregables concretos. Aunque en proyectos ágiles se ejecutan en ciclos cortos y a veces se solapan, el orden lógico se mantiene: no tiene sentido escribir casos de prueba sin haber entendido los requisitos.
Antes de entrar al detalle, este es el esquema completo. Úsalo como mapa y luego revisa cada fase con sus actividades principales.
Fases del ciclo de vida del testing
Análisis de requisitos
Se identifican los aspectos comprobables y los criterios de aceptación.
Planificación de pruebas
Se define la estrategia, el alcance, los recursos y los plazos.
Desarrollo de casos de prueba
Se redactan los casos y se preparan los datos de prueba.
Configuración del entorno
Se prepara un entorno lo más parecido posible a producción.
Ejecución de pruebas
Se ejecutan los casos y se registran los defectos encontrados.
Análisis de resultados
Se evalúan métricas como cobertura, densidad de defectos y tasa de aprobación.
Cierre de pruebas
Se emite el informe final y se documentan las lecciones aprendidas.
1. Análisis de requisitos
El equipo de pruebas revisa los requisitos que aportan las partes interesadas para decidir qué se puede probar y cómo. Aquí se aclaran las ambigüedades junto con el equipo de desarrollo, porque un requisito vago produce pruebas vagas.
Las actividades típicas son identificar requisitos comprobables, entender los criterios de aceptación, priorizar y definir qué tipos de prueba hacen falta, como pruebas de humo, de regresión o manuales.
2. Planificación de pruebas
Es la fase que sienta las bases. La persona responsable de pruebas prepara el plan de pruebas, un documento que funciona como plano de todo el proceso: estrategia, alcance, objetivos, recursos, plazos y entregables.
En la práctica implica estimar esfuerzos, identificar riesgos con sus medidas de mitigación, elegir herramientas y personal, y dejar listo el entorno que se usará. Un plan realista evita el clásico recorte de pruebas de última hora.
3. Desarrollo de casos de prueba
Con el plan aprobado, se redactan casos detallados. Cada uno indica los datos de entrada, los pasos de ejecución y el resultado esperado, y se acompaña de los datos de prueba necesarios.
Los casos se revisan y se aprueban, y se enlazan con los requisitos mediante una matriz de trazabilidad. Así se comprueba que ningún requisito queda sin cobertura.
4. Configuración del entorno de pruebas
Aquí se prepara el hardware y el software donde se probará. El entorno debe imitar a producción tanto como sea posible, porque un resultado obtenido en condiciones muy distintas pierde fiabilidad.
Se montan servidores y redes, se instalan las herramientas, se configura todo según el plan y se verifica con una prueba de humo antes de empezar a ejecutar casos.
5. Ejecución de pruebas
El equipo ejecuta los casos preparados, manuales y automatizados según la estrategia, y compara los resultados con los esperados. Los defectos se registran en una herramienta de seguimiento con la información necesaria para reproducirlos.
Cuando el equipo de desarrollo corrige un defecto, se repite la prueba y se ejecutan pruebas de regresión para confirmar que el arreglo no rompió otra cosa.
6. Análisis de resultados
Se revisan los resultados para valorar la calidad real del software y detectar los defectos críticos. Se analizan métricas como la cobertura de pruebas, la densidad de defectos y la tasa de casos aprobados.
También se buscan patrones, se priorizan los defectos por gravedad e impacto y se prepara un informe para las partes interesadas, que es la base para decidir si el producto está listo.
7. Cierre de pruebas
El cierre marca el final formal. El equipo comprueba que se cumplieron los criterios de finalización y emite un informe con los casos ejecutados, los defectos hallados y la calidad global.
Es la fase que más se omite y la que más enseña: la reunión retrospectiva recoge lecciones aprendidas y los artefactos se archivan para el siguiente proyecto.
¿Qué son los criterios de entrada y salida en el ciclo de vida del testing?
Los criterios de entrada y salida son los puntos de control del STLC. Aseguran que cada fase se completa correctamente antes de pasar a la siguiente, y evitan arrancar una ejecución sin plan o cerrar una fase con trabajo pendiente.
Los criterios de entrada describen las condiciones que deben cumplirse antes de empezar una fase. Los de salida describen las condiciones para darla por concluida. Tomemos como ejemplo la fase de ejecución de pruebas.
| Tipo de criterio | Ejemplos para la fase de ejecución |
|---|---|
| Criterios de entrada | Plan de pruebas aprobado, casos preparados y revisados, entorno configurado y verificado, datos de prueba listos. |
| Criterios de salida | Todos los casos planificados ejecutados, defectos críticos resueltos o aplazados con acuerdo, análisis de resultados completado, cobertura por encima del umbral definido. |
Lo importante es que los umbrales se definan por escrito y de antemano. Si “suficiente cobertura” se decide al final, siempre acabará siendo la que alcanzó el equipo, sea cual sea.
Los criterios también facilitan las conversaciones difíciles. Cuando el cliente pide adelantar la entrega, el equipo puede mostrar qué criterios de salida siguen sin cumplirse y qué riesgo implica seguir adelante.
¿Cuál es la diferencia entre SDLC y STLC?
El ciclo de vida del desarrollo de software (SDLC) abarca todo el recorrido de un producto: recopilación de requisitos, diseño, desarrollo, pruebas, despliegue y mantenimiento. El STLC es un subconjunto del SDLC que se ocupa solo de las actividades de prueba.
| Aspecto | SDLC | STLC |
|---|---|---|
| Alcance | Todo el proceso de desarrollo del producto. | Solo las actividades de prueba. |
| Fases | Requisitos, diseño, desarrollo, pruebas, despliegue y mantenimiento. | Análisis de requisitos, planificación, casos, entorno, ejecución, resultados y cierre. |
| Objetivo | Entregar un producto funcional. | Asegurar que el producto cumple los estándares de calidad. |
No compiten entre sí: se ejecutan en paralelo. En un modelo ágil, cada iteración del SDLC contiene un mini ciclo de pruebas, y la calidad deja de ser una etapa para convertirse en una actividad constante.
Entender esta relación evita un error frecuente, que es tratar las pruebas como la casilla final del SDLC. Si el STLC empieza con el análisis de requisitos, el equipo de pruebas debe estar presente desde el primer día.
¿Qué beneficios aporta el ciclo de vida del testing?
Aplicar un proceso de pruebas estructurado repercute en la calidad, el costo y la relación entre equipos. Estos son los beneficios principales.
- Mayor calidad: un enfoque estructurado permite identificar y resolver defectos pronto, y el resultado es un software que cumple lo que esperan los clientes.
- Menos riesgo, porque los problemas se identifican en las primeras etapas y se atienden antes de provocar retrasos o fracasos del proyecto.
- Pruebas más rentables: los defectos hallados tarde suelen ser mucho más caros de resolver que los detectados a tiempo.
- Mejor cobertura, ya que el método sistemático reduce la probabilidad de que queden defectos sin detectar.
- Colaboración más fluida entre desarrollo y pruebas, con un proceso alineado con los objetivos del proyecto.
- Más satisfacción del cliente, porque entregar software que cumple los estándares genera confianza en el producto.
Todos estos beneficios parten de lo mismo: hacer visible el estado de la calidad. Cuando el proceso está documentado, las decisiones de lanzamiento dejan de basarse en intuiciones.
Ejemplos de ciclo de vida del testing según el tipo de proyecto
Las siete fases son las mismas, pero su peso cambia según el contexto. En un proyecto en cascada, con requisitos estables, el plan de pruebas es extenso y cada fase tiene criterios formales de entrada y salida. Es habitual en sistemas bancarios o de salud, donde se exige trazabilidad completa.
En un equipo ágil, el ciclo se comprime en cada sprint: los requisitos se analizan en el refinamiento, los casos se escriben junto a las historias y la automatización de regresión corre en cada integración. El cierre se convierte en la retrospectiva del sprint.
En una aplicación móvil o web de consumo, el entorno de pruebas cobra especial importancia, porque hay que cubrir múltiples dispositivos, navegadores y conexiones. Aquí el ciclo suele incluir también pruebas con personas usuarias reales.
Conclusión
El ciclo de vida del testing integra las pruebas en todo el desarrollo y las convierte en una disciplina medible: siete fases, criterios claros de entrada y salida, y un cierre que alimenta el siguiente proyecto. Con él, el equipo detecta defectos pronto, reduce riesgos y entrega software con más confianza.
Ahora bien, un producto puede superar todas las pruebas funcionales y seguir siendo difícil de usar. Por eso conviene sumar a tu proceso las pruebas de usabilidad, incluso en su versión remota (consulta nuestra guía de pruebas de usabilidad remotas), para ver cómo se desenvuelven personas reales con tu producto.
Si quieres validar la experiencia con usuarios, QuestionPro UX te permite reclutar participantes, realizar entrevistas moderadas y no moderadas en vídeo y analizar los resultados con apoyo de inteligencia artificial.
Preguntas frecuentes sobre el ciclo de vida del testing
Son siete: análisis de requisitos, planificación de pruebas, desarrollo de casos de prueba, configuración del entorno, ejecución de pruebas, análisis de resultados y cierre de pruebas. Cada fase tiene entregables propios y debe cumplir sus criterios de salida antes de que empiece la siguiente.
El SDLC cubre todo el desarrollo del software, desde los requisitos hasta el mantenimiento, mientras que el STLC es un subconjunto centrado solo en las actividades de prueba. En la práctica se ejecutan en paralelo, y el STLC empieza con el análisis de requisitos del propio SDLC.
Son las condiciones que deben cumplirse para iniciar o concluir cada fase del STLC. Por ejemplo, para empezar la ejecución se necesita un plan aprobado y un entorno verificado, y para terminarla se exige haber ejecutado todos los casos planificados y resuelto los defectos críticos.
Debe empezar en la fase de requisitos del proyecto, no cuando el código está terminado. Involucrar al equipo de pruebas desde el principio permite detectar ambigüedades y requisitos no comprobables cuando corregirlos todavía es barato.
Sí. En entornos ágiles y DevOps las fases se comprimen en cada iteración y se apoyan en automatización y pruebas continuas. El proceso sigue siendo el mismo, pero los ciclos son más cortos y los criterios se revisan con cada sprint.
