Profundizando en 2.1.1. Impacto del ciclo de vida del desarrollo del software en las pruebas – ISTQB CTFL v4.0

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

En nuestra actividad como testers ágiles podemos estar participando en diferentes tipos de proyectos y debemos conocer el concepto y alcance de los modelos de SDLC (en español: Ciclo de Vida de Desarrollo de Software) como así también, los diferentes métodos de desarrollo que se apliquen de acuerdo al modelo seleccionado, ya que nuestras pruebas se deben adaptar, más que nada por el impacto que esto tiene en el testing.

En este artículo me ocupo de profundizar estos aspectos y entender que cuando se decide desarrollar un producto aplicando un modelo determinado, como agile testers debemos reconocer y tener en el radar el impacto que tiene como para que podamos hacer un buen testing.

El impacto de la elección puede darse en :

  • el Alcance de las actividades de prueba.
  • el Nivel de detalle de la documentación de la prueba.
  • la Elección de técnicas de prueba y enfoque de prueba.
  • el Alcance de la automatización de pruebas.
  • el Rol y responsabilidades de un probador.

Todo esto implica que deberemos aplicar determinada metodología y determinadas técnicas dependiendo del modelo elegido.

Proyecto ejemplo

A continuación estaré ampliando conceptualmente cada uno de estos puntos que pueden verse afectados/impactos, para luego dar un ejemplo sobre la base de un proyecto en el que se está desarrollando una aplicación web responsive, para vender paquetes turísticos.

Alcance de las actividades de prueba

En un ciclo de vida ágil, las pruebas son continuas y paralelas al desarrollo, permitiéndonos detectar defectos de manera temprana.

En un ciclo de vida en cascada, las pruebas (por lo general) se concentran al final, aumentando el riesgo de encontrar defectos mayores, de manera tardía y con todo lo que eso conlleva para nosotros luego.

Considerando el proyecto ejemplo, tomaré el modelo ágil donde el tester automatizador crea  casos de prueba en formato gherkin y ejecuta el script a medida que se desarrolla cada funcionalidad, como la búsqueda de paquetes. Las pruebas se ejecutan continuamente a lo largo del sprint  lanzadas desde Jenkins y generándose el reporte de resultados desde Allure Report que le llega al equipo para la evaluación de parte de cada uno de sus miembros dependiendo de su rol, verificando que el botón «Buscar» solo se habilita cuando se completan todos los campos obligatorios. Esto permite una detección temprana de defectos y ajustes rápidos, a diferencia de un enfoque en cascada o tradicional donde las pruebas solo ocurrirían al final, retrasando la corrección de errores.

Nivel de detalle de la documentación de la prueba

En un ciclo de vida ágil, la documentación de pruebas debe ser mínima (desde mi punto de vista diría lo suficiente para que nos permita iniciar nuestro trabajo) y se enfoca en lo esencial para facilitar la colaboración y la adaptabilidad.

En ciclo de vida tradicional, como el modelo en cascada, la documentación es extensa y detallada.

Considerando el proyecto ejemplo, tomaré el modelo ágil donde la documentación de pruebas debe mantenerse mínima. Por ejemplo, en Jira Software con integración a Xray, documentamos brevemente cada escenario de prueba para la funcionalidad «Buscar paquete». Esto incluye condiciones de prueba básicas como “si el campo ‘¿Adónde quieres viajar?’ está vacío, el botón ‘Buscar’ debe permanecer inhabilitado”. Este enfoque ágil evita una documentación excesiva y se centra en pruebas rápidas y colaborativas, permitiendo al equipo reaccionar rápidamente a los cambios.

Elección de técnicas de prueba y enfoque de prueba

En Agile, se favorecen las técnicas de prueba exploratorias y automatizadas para adaptarse a cambios rápidos y constantes.

En ciclos de vida tradicionales, se utilizan técnicas más formales y planificadas.

Considerando el proyecto ejemplo, tomaré el modelo ágil donde el tester automatizador aplica pruebas exploratorias para identificar rápidamente problemas potenciales en la interfaz de usuario responsive y pruebas automatizadas con Selenium WebDriver para verificar la lógica de activación del botón «Buscar». Este enfoque mixto es ideal en Agile, donde se necesitan respuestas rápidas y flexibilidad para adaptar las pruebas a cambios en los requisitos del sprint. 

Alcance de la automatización de pruebas

En un entorno Agile, la automatización es clave para soportar entregas continuas. En SDLC tradicionales, la automatización puede ser limitada debido a su estructura secuencial.

Considerando el proyecto ejemplo, la automatización de pruebas cubre escenarios clave como la validación de campos obligatorios en la búsqueda de paquetes. Scripts de Selenium WebDriver verifican que el botón «Buscar» se habilite solo cuando todos los campos obligatorios están llenos. La automatización permite ejecutar pruebas de regresión rápidamente mediante la programación de un job desde Jenkins cada vez que hay un nuevo despliegue, asegurando que las funcionalidades existentes no se vean afectadas por los cambios. recientes.

Rol y responsabilidades de un probador

En Agile, los testers forman parte del equipo de desarrollo junto con los desarrolladores del código para la aplicación (por así decirlo), colaborando estrechamente junto con el PO (Product Owner) para mejorar la calidad.

En modelos tradicionales, los testers pueden ser un equipo separado, enfocado en la fase final de prueba (por lo general).

Considerando el proyecto ejemplo, el tester automatizador trabaja estrechamente con los developers desde el inicio del sprint para definir criterios de aceptación claros para la funcionalidad «Buscar paquete». Participa en sesiones de planificación y retroalimentación, ayudando a identificar riesgos y proponiendo soluciones. Este rol proactivo asegura que las pruebas estén integradas en el desarrollo, mejorando la calidad y eficiencia del proceso, a diferencia de un enfoque tradicional donde el tester solo intervendría en la fase final.

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.