Cuando un error llega a producción, la causa no suele ser que alguien haya olvidado ejecutar una prueba. Es que nunca se cuestionó un requisito, los datos de la prueba estaban equivocados o nadie estuvo de acuerdo en lo que significaba “hecho”. El ciclo de vida de las pruebas de software aborda esos problemas dando a las pruebas una estructura clara desde el primer requisito hasta el informe final.

Esta guía explica cada fase y luego sigue una característica ilustrativa a través de todas ellas: una página de inicio de sesión que bloquea una cuenta después de cinco intentos fallidos. Las fuentes no están totalmente de acuerdo sobre el número de fases. Verás modelos con siete u ocho, pero en su mayoría dividen el mismo trabajo de forma diferente. Usamos la versión de seis fases ampliamente enseñada.

¿Qué es el STLC?

El STLC es una serie definida de actividades de prueba que se llevan a cabo para confirmar que el software cumple con sus requisitos. Cada fase tiene un objetivo, entradas y salidas, de modo que las pruebas sean planificadas y rastreables en lugar de improvisarse al final.

Los beneficios son prácticos. Los evaluadores participan temprano, cuando los defectos son más baratos de reparar. El esfuerzo va hacia los mayores riesgos. Y cuando un gerente pregunta “¿estamos listos para liberarlo?”, el equipo puede responder con evidencia.

Las seis fases del STLC de un vistazo

Criterios de entrada son las condiciones que deben cumplirse antes de que comience una fase. Criterios de salida son ​​las condiciones que deben cumplirse antes de que finalice. Impiden que un equipo, por ejemplo, ejecute pruebas en una compilación defectuosa y pierda un día.

Fase 1: Análisis de requisitos

Los evaluadores estudian los requisitos para descubrir qué se puede probar y qué no está claro. Este suele ser el lugar más barato para prevenir un error, ya que una pregunta cuesta mucho menos que una solución de producción.

• Entrada: documentos de requisitos o historias de usuarios están disponibles.
• Actividades: identificar necesidades funcionales y no funcionales, hacer preguntas, evaluar riesgos y decidir qué podría automatizarse.
• Salir: se responden las preguntas abiertas y se inicia la matriz de trazabilidad de requisitos (RTM).
• Entregables: una lista de requisitos comprobables y el RTM.

Ejemplo de inicio de sesión. La historia dice “bloquear la cuenta después de cinco intentos fallidos”. Un buen evaluador pregunta: ¿cinco en qué período? ¿Cómo se desbloquea? ¿Un inicio de sesión exitoso restablece el recuento? ¿Qué mensaje se muestra? Cada respuesta se convierte en algo comprobable.

Fase 2: planificación de pruebas

El equipo decide el alcance, el enfoque, las personas, las herramientas, el cronograma y los riesgos. El cable de prueba suele ser el propietario de esta fase.

• Entrada: requisitos analizados y una evaluación inicial de riesgos.
• Actividades: define el alcance, estima el esfuerzo, selecciona herramientas, asigna roles y establece criterios de salida para fases posteriores.
• Salir: el plan de pruebas es revisado y aprobado.
• Entregables: el plan de pruebas y estimaciones de esfuerzo.

Ejemplo de inicio de sesión. Alcance: reglas de bloqueo, restablecimiento y mensajes de error en la web y el móvil. Fuera de alcance: inicio de sesión único, manejado por otro equipo. El mayor riesgo es bloquear a usuarios genuinos, por lo que recibe la mayor atención. Si no está seguro de en qué se diferencia un plan de una estrategia, lea plan de prueba frente a estrategia de prueba.

Fase 3: desarrollo de casos de prueba

Aquí es donde los evaluadores escriben los casos de prueba detallados, los scripts de automatización y los datos de prueba.

• Entrada: un plan de prueba aprobado y requisitos estables.
• Actividades: escribir y revisar casos de prueba, preparar datos, programar verificaciones automatizadas y actualizar el RTM.
• Salir: los casos de prueba y los datos están revisados ​​y listos.
• Entregables: casos de prueba, scripts y datos de prueba.

Observe que TC-01 y TC-02 prueban ambos lados del límite, lo que proviene directamente del análisis del valor límite. Para obtener más información sobre cómo escribirlos correctamente, consulte cómo escribir casos de prueba.

Fase 4: configuración del entorno de prueba

Las pruebas necesitan un lugar realista para ejecutarse: los servidores, los datos, las cuentas, los navegadores y el acceso a la red adecuados. Esta fase a menudo se ejecuta en paralelo con la fase 3 y puede estar a cargo de desarrolladores o un equipo de DevOps.

• Entrada: un plan de prueba, una descripción general de la arquitectura y requisitos del entorno.
• Actividades: configurar hardware o contenedores, cargar datos, configurar el acceso e instalar la compilación.
• Salir: el ambiente está listo y pasa una prueba de humo.
• Entregables: un entorno de trabajo y el resultado de una prueba de humo.

Ejemplo de inicio de sesión. La preparación obtiene cuentas de prueba en estados conocidos, junto con un temporizador de bloqueo acortado para que los evaluadores no tengan que esperar. Una prueba de humo rápida confirma que el inicio de sesión se carga antes de que comience la ejecución completa. Los contenedores ayudan a mantener la coherencia de los entornos, como se muestra en nuestro tutorial de Docker Compose.

Fase 5: Ejecución de la prueba

Los evaluadores ejecutan las pruebas planificadas, comparan los resultados reales y esperados e informan sobre los defectos. Los errores corregidos se vuelven a probar y las áreas relacionadas reciben pruebas de regresión.

• Entrada: los casos de prueba están listos, el entorno funciona y se ha entregado una compilación.
• Actividades: ejecutar pruebas, registrar resultados, registrar defectos, volver a probar correcciones y actualizar el RTM.
• Salir: se ejecutan las pruebas planificadas y los defectos se solucionan o se aceptan formalmente.
• Entregables: resultados de pruebas e informes de defectos.

Ejemplo de inicio de sesión. TC-04 falla: con dos navegadores, el contador solo llega a cuatro. El evaluador registra el error con pasos claros y evidencia, como se describe en cómo escribir un informe de error. Una vez solucionado, se vuelve a ejecutar TC-04 y las comprobaciones de inicio de sesión relacionadas pasan por la lista de verificación de regresión.

Fase 6: Cierre de la prueba

Esta fase suele omitirse, lo cual es una pena, ya que es la forma en la que un equipo mejora. El equipo evalúa el ciclo, archiva su trabajo y registra lo aprendido.

• Entrada: la ejecución está completa y se conoce el estado del defecto.
• Actividades: verificar criterios de salida, analizar tendencias de defectos, archivar activos de prueba y realizar una retrospectiva.
• Salir: se firma el informe de cierre.
• Entregables: el informe de cierre y lecciones aprendidas.

Ejemplo de inicio de sesión. El informe muestra que los cinco casos se superaron después de una solución. La lección es que la concurrencia solo se probó tarde, por lo que las funciones futuras con contadores agregarán ese escenario durante el diseño.

STLC frente a SDLC

El SDLC, o ciclo de vida de desarrollo de software, cubre la construcción de todo el producto. El STLC es la parte centrada en las pruebas y corre junto a ella.

El análisis de requisitos en el SDLC alimenta el análisis de requisitos en el STLC, y el desarrollo ofrece integraciones para la ejecución de pruebas. Las pruebas no tienen que esperar hasta que finalice la codificación. Empezar temprano es lo que la gente quiere decir con “giro a la izquierda”.

STLC en Agile y DevOps

Las fases pueden parecer un proceso largo y unidireccional, pero no tienen por qué serlo. En Agile, las mismas actividades se reducen y se repiten dentro de cada sprint, a menudo en horas en lugar de semanas:

• El análisis de requisitos ocurre en el refinamiento del trabajo pendiente, a través de preguntas sobre la historia del usuario.
• La planificación ocurre en la planificación de sprints, con notas ligeras en lugar de documentos largos.
• El diseño de pruebas ocurre junto con la codificación, a menudo como criterios de aceptación y pruebas automatizadas.
• La configuración del entorno se automatiza a través de contenedores e infraestructura como código.
• La ejecución se ejecuta continuamente en una canalización de CI/CD.
• El cierre pasa a formar parte de la revisión y retrospectiva del sprint.

Quédese con lo útil y escale el papeleo según el riesgo. Una pequeña herramienta interna puede necesitar una breve lista de verificación, mientras que un sistema bancario puede necesitar aprobaciones formales por razones regulatorias.

Errores comunes

• Incorporación tardía de los evaluadores. Los errores encontrados en los requisitos son mucho más baratos que los encontrados después del lanzamiento.
• Criterios de salida vagos. Sin ellos, los plazos toman la decisión por usted.
• Pruebas en un entorno deficiente. Las fallas causadas por datos o configuraciones incorrectos hacen perder tiempo y erosionan la confianza.
• Saltar el cierre. El equipo luego repite los mismos errores en el siguiente ciclo.
• Seguirlo demasiado rígidamente. El STLC es una guía. Los documentos pesados ​​no significan automáticamente una mejor calidad.

Conclusión

El ciclo de vida de las pruebas de software es simplemente una respuesta disciplinada a seis preguntas: ¿qué probamos, cómo, con qué casos, dónde, qué pasó y qué aprendimos? Mire su próxima función y compruebe cuál de esas preguntas suele omitir su equipo. Arreglar esa brecha probablemente le dará la mayor ganancia.

Preguntas frecuentes

sigue aprendiendo