El software no aparece de una sola vez. Normalmente atraviesa varias etapas: se identifica una necesidad, se analizan requisitos, se diseña una solución, se desarrolla, se prueba, se publica y luego se mantiene. A este recorrido se lo conoce como ciclo de vida del software.
El testing debe acompañar ese ciclo. Si las pruebas se dejan solo para el final, muchos defectos se descubren tarde, cuando corregirlos puede ser más difícil y costoso. En cambio, cuando el testing participa desde el inicio, ayuda a prevenir problemas, aclarar dudas y reducir riesgos.
En este tema veremos cómo se relaciona el testing con cada etapa del desarrollo de software.
El ciclo de vida del software es el conjunto de etapas por las que pasa un producto desde que surge la idea hasta que se retira o deja de mantenerse.
Aunque cada organización puede trabajar de manera distinta, un ciclo típico incluye:
Estas etapas no siempre ocurren de forma lineal. En metodologías ágiles, por ejemplo, se repiten en ciclos pequeños. Pero la idea general se mantiene: el software evoluciona y el testing debe acompañar esa evolución.
La etapa de requisitos define qué debe hacer el sistema. Si los requisitos son ambiguos, incompletos o contradictorios, es muy probable que el producto tenga defectos.
En esta etapa, el testing puede aportar mucho aunque todavía no exista código. Algunas tareas útiles son:
Un requisito poco claro podría decir:
Este requisito es difícil de probar porque no define qué significa "rápido" ni qué significa "adecuado". Un tester podría ayudar a transformarlo en algo más verificable:
Ahora sí es posible diseñar pruebas concretas. Esta mejora ocurrió antes de programar, por lo tanto evitó posibles defectos futuros.
Durante el diseño se define cómo se organizará la solución: pantallas, flujos, componentes, base de datos, integraciones, permisos y arquitectura general.
El testing puede participar revisando preguntas como:
Diseñar pensando en pruebas facilita el trabajo posterior. Un sistema testeable permite observar resultados, preparar datos y aislar problemas con menos esfuerzo.
Durante la implementación, los desarrolladores escriben código y realizan verificaciones técnicas. En esta etapa aparecen pruebas como las unitarias, pruebas de componentes y validaciones iniciales de integración.
El testing puede colaborar de varias maneras:
En equipos ágiles, esta colaboración ocurre de forma continua. La funcionalidad no se "tira por encima de una pared" al área de testing, sino que se construye y valida con comunicación frecuente.
Cuando una funcionalidad está lista para probarse, se ejecutan pruebas con mayor foco en el comportamiento del sistema. Aquí se verifican requisitos, flujos de usuario, casos alternativos, errores esperados y posibles regresiones.
Algunas actividades habituales son:
Esta etapa es importante, pero no debería ser la primera vez que alguien piensa en calidad. Si el testing participó antes, la etapa formal será más ordenada y efectiva.
Antes de publicar una versión, el equipo necesita comprobar que los riesgos principales están controlados. En esta etapa suelen ejecutarse pruebas de humo, pruebas de regresión seleccionadas y validaciones de configuración.
Algunas preguntas relevantes son:
El testing antes del despliegue no debería descubrir por primera vez problemas básicos. Su objetivo es confirmar que la entrega está en condiciones razonables.
Una vez publicada la versión, pueden realizarse pruebas en producción o verificaciones posteriores al despliegue. Estas pruebas deben hacerse con cuidado, especialmente si el sistema maneja datos reales.
Ejemplos de verificaciones posteriores son:
Estas pruebas no reemplazan las pruebas previas. Son una capa adicional para detectar problemas reales de despliegue, configuración o ambiente.
Después de publicar, el software sigue cambiando. Se corrigen defectos, se agregan funcionalidades, se actualizan dependencias, se modifican reglas de negocio y se ajustan configuraciones.
El mantenimiento requiere testing porque cada cambio puede generar efectos secundarios. Algunas actividades habituales son:
Un sistema vivo necesita pruebas vivas. Si el producto cambia, los casos de prueba también deben mantenerse.
El testing puede integrarse de distintas formas según el modelo de desarrollo utilizado.
| Modelo | Características | Relación con testing |
|---|---|---|
| Cascada | Etapas secuenciales: requisitos, diseño, desarrollo, pruebas y entrega. | El testing suele concentrarse más tarde, aunque puede participar revisando documentos desde el inicio. |
| Iterativo | El producto evoluciona en versiones parciales. | Las pruebas se repiten y ajustan en cada iteración. |
| Ágil | Trabajo incremental con entregas frecuentes y colaboración continua. | Testing acompaña cada historia, sprint o incremento. |
| DevOps | Integración entre desarrollo, operaciones y entrega continua. | Se automatizan verificaciones y se monitorea el sistema en producción. |
El modelo cambia la forma de organizar el trabajo, pero no elimina la necesidad de probar. Solo modifica cuándo, cómo y con qué frecuencia se realizan las pruebas.
La expresión shift left se usa para describir la idea de mover actividades de calidad hacia etapas más tempranas del ciclo de vida. En lugar de esperar al final, el equipo intenta detectar problemas desde requisitos, diseño y desarrollo.
Ejemplos de shift left son:
El objetivo no es eliminar las pruebas finales, sino evitar que sean el primer momento donde aparecen dudas importantes.
También existe la idea de shift right, que consiste en obtener información después del despliegue. Esto incluye monitoreo, métricas, alertas, análisis de errores reales y observación del comportamiento de los usuarios.
Algunos ejemplos son:
Shift right no significa probar menos antes de publicar. Significa complementar las pruebas previas con información del mundo real.
La trazabilidad permite relacionar requisitos, casos de prueba, defectos y versiones. Ayuda a responder preguntas como:
En proyectos pequeños puede bastar con una planilla ordenada. En proyectos más grandes se usan herramientas de gestión de pruebas, tableros de tareas, sistemas de seguimiento de defectos e integración con repositorios de código.
Supongamos que se quiere agregar la funcionalidad "recuperar contraseña". El testing podría participar así:
| Etapa | Aporte del testing |
|---|---|
| Requisitos | Preguntar cuánto dura el enlace, qué mensaje se muestra y qué ocurre si el correo no existe. |
| Diseño | Revisar flujo, mensajes, seguridad del enlace y datos necesarios para probar. |
| Desarrollo | Compartir casos importantes y validar versiones parciales. |
| Pruebas | Ejecutar casos exitosos, errores, vencimiento de enlaces, usuarios bloqueados y regresión de inicio de sesión. |
| Despliegue | Confirmar configuración de correo, ambiente y disponibilidad del servicio. |
| Mantenimiento | Agregar casos si aparecen incidencias reales o cambia la política de seguridad. |
Este ejemplo muestra que el testing puede aportar valor en todo el recorrido de una funcionalidad, no solo al final.
Algunas prácticas suelen generar problemas:
Estos errores suelen aumentar retrabajo, incertidumbre y defectos tardíos.
El Testing de Software no es una etapa aislada al final del desarrollo. Es una actividad que puede aportar valor desde el análisis inicial hasta el mantenimiento del producto en producción.
Cuando el testing participa temprano, ayuda a prevenir defectos. Cuando acompaña el desarrollo, mejora la comunicación. Cuando se ejecuta antes del despliegue, aporta confianza. Y cuando continúa después de publicar, permite aprender del uso real.
En el próximo tema estudiaremos la diferencia entre verificación y validación, dos conceptos fundamentales para comprender qué significa construir correctamente un producto y construir el producto correcto.