Profundizando en los Modelos de Ciclo de Vida del Desarrollo de Software

  • Autor de la entrada:
  • Categoría de la entrada:Agile / ISTQB

Cuando los responsables de una gerencia de tecnología o bien, del área técnica a cargo de un proyecto deciden el modelo de desarrollo de software que se implementará, deberemos prestar especial atención a todo lo relacionado con la planificación, ejecución y gestión del control de calidad. Los modelos ágiles, es decir aquellos que son más flexibles y adaptativos, tienden a facilitarnos un mejor proceso de QA (Aseguramiento de la Calidad) al poder integrar pruebas de manera continua y permitir una respuesta rápida a defectos que podamos detectar y a cambios que se nos presenten durante cada sprint. Sin embargo, si te encuentras bajo un modelo secuencial,  mucho de lo anterior no lo podrás llevar a cabo porque tendrás ciertas restricciones vinculadas con la efectividad del control de calidad debido a que su estructura es rígida y lineal.

Por lo tanto y como podrás entender, es importante conocer no sólo el concepto sino las prácticas que se deben seguir en cada modelo ya que deberemos adaptar nuestro testing.

¿Cuál es el impacto bajo el enfoque de QA?

  • Flexibilidad y Adaptabilidad: Los modelos ágiles e iterativos facilitan que nos vayamos adaptando rápidamente a los cambios con una retroalimentación constante, y de esta manera se promueve una mejora continua en el control de calidad entre todo el equipo.
  • Costo y Tiempo de Corrección: En los modelos secuenciales o tradicionales, la corrección de errores puede ser más costosa y prolongada ya que detectamos tarde a los defectos, debido a que se deben cumplir con ciertas etapas previas.
  • Colaboración y Transparencia: En los modelos iterativos e incrementales, la colaboración entre nosotros y los desarrolladores es más estrecha, lo que mejora la comunicación y la transparencia sobre el estado de la calidad del producto.
  • Automatización de Pruebas: En los modelos iterativos y ágiles, la automatización de pruebas es más factible y beneficiosa, ya que permite pruebas continuas e integradas en el ciclo de desarrollo, mejorando la eficiencia de QA.

Breve explicación de los modelos SDLC

  • Waterfall Model: Un modelo secuencial donde cada fase del desarrollo debe completarse antes de que comience la siguiente. Es rígido y difícil de modificar.

  • V-Model: Un modelo secuencial que representa una relación de verificación y validación entre fases de desarrollo y pruebas. Cada fase de desarrollo tiene una fase de prueba correspondiente.

  • Spiral Model: Un modelo iterativo que combina elementos del modelo en cascada y la creación de prototipos, enfatizando la evaluación de riesgos en cada iteración.

  • Prototyping Model: Un modelo iterativo donde se crea un prototipo funcional de la aplicación para recoger feedback del usuario antes del desarrollo completo.

  • Unified Process: Un modelo incremental donde el desarrollo ocurre en ciclos o incrementos, permitiendo mejoras continuas y adaptaciones según feedback constante

Ejercicio con un proyecto ejemplo

Considerando un proyecto en el que se desarrolla una aplicación web responsive para vender paquetes turísticos (Nota: este ejemplo de proyecto lo tengo desarrollado en artículos anteriores), describo brevemente cómo se podría enfocar en cada modelo el control de calidad y así saber cómo adaptarnos. 

Waterfall Model

En el modelo Waterfall, el proyecto se gestionaría de manera secuencial. Primero, se definirían claramente los requisitos de la funcionalidad «Buscar paquete» y se documentarían exhaustivamente. Luego, el diseño de la interfaz y la arquitectura del backend se completaría antes de comenzar el desarrollo. La fase de desarrollo implicaría la codificación de la aplicación de acuerdo con los requisitos definidos, seguida de pruebas exhaustivas. La validación de cada fase sería crucial antes de pasar a la siguiente, lo que significa que cualquier error encontrado en una fase posterior podría ser costoso y requerir un retroceso significativo.

V-Model

El V-Model, siendo una extensión del Waterfall, añadiría una capa de pruebas en paralelo a cada fase de desarrollo. Por ejemplo, mientras se definen los requisitos de la funcionalidad «Buscar paquete», se diseñarían simultáneamente los casos de prueba correspondientes. Durante la fase de diseño, también se prepararían planes de pruebas de integración. Esto asegura una validación más estructurada y temprana en el ciclo de desarrollo, minimizando el riesgo de errores no detectados. En cada paso, los resultados de desarrollo y las pruebas deben coincidir, facilitando una mejor calidad del software desde el principio.

Spiral Model

En el modelo Spiral, el desarrollo de la aplicación web sería iterativo, comenzando con la funcionalidad principal como «Buscar paquete» en una primera iteración. Se crearía un prototipo inicial, seguido de pruebas y análisis de riesgos. Basado en los resultados y feedback de los usuarios, se realizarían ajustes y se agregarían características adicionales en cada ciclo sucesivo. Este enfoque es beneficioso para proyectos con alta incertidumbre o requisitos que pueden evolucionar, permitiendo una constante adaptación y mejora del producto.

Prototyping Model

Aquí, se desarrollaría un prototipo funcional básico de la funcionalidad «Buscar paquete» que permitiría a los usuarios interactuar con la interfaz de usuario sin necesidad de backend completo. Los usuarios podrían probar el prototipo y proporcionar feedback sobre la experiencia de usuario y las características necesarias. Este feedback se utilizaría para refinar el diseño antes de proceder con el desarrollo completo. Este enfoque es ideal para validar rápidamente los requisitos y asegurar que la aplicación se alinee con las expectativas del usuario.

Unified Process (UP)

El proceso unificado aplicaría un enfoque incremental e iterativo, dividiendo el desarrollo de la aplicación en fases claras como incepción, elaboración, construcción, y transición. Cada fase incluiría múltiples iteraciones donde se desarrollan incrementos funcionales de la aplicación, como la funcionalidad «Buscar paquete» primero y luego otras funciones adicionales en fases posteriores. Cada iteración incluiría tareas de análisis, diseño, implementación, y pruebas. Este enfoque asegura una evolución continua del producto con mejoras basadas en feedback constante, permitiendo ajustes en la arquitectura o en el diseño según sea necesario.

Comentario final

Si te ha servido este contenido basado en el programa de estudios del ISTQB CTFL v4.0, me alegro y mucho. También te cuento que me puedes seguir en LinkedIn e interactuar con otros colegas testers que me siguen y que están interesados en contenidos relacionados con agile testing, inteligencia artificial y OKRs aplicado a testing. Muchas gracias

Gus Terrera

Apasionado por el agile testing y la ia.