Pruebas de regresión funcional en proyectos ágiles

/Pruebas de regresión funcional en proyectos ágiles

Pruebas de regresión funcional en proyectos ágiles

Seamos claros, está de moda implementar “metodologías ágiles” en los proyectos de desarrollo y mantención de software, porque en nuestras empresas nos pidieron “mejorar los tiempos de entrega y reducir los costos de desarrollo”; sin mencionar que ahora también debemos “ser ágiles” y “trabajar colaborativamente”.… Pero, si las metodologías ágiles realmente funcionan y son tan simples como parecen, ¿por qué es tan difícil lograr estos objetivos en la práctica?.

La respuesta a esta pregunta es que las Metodologías Ágiles por si solas no logran “mejorar los tiempos de entrega ni reducir los costos de desarrollo”; hace falta incluir la automatización de 3 tareas claves para la entrega de una nueva versión del software en producción, estas son: la compilación, las pruebas y el despliegue. En un proceso de desarrollo iterativo e incremental como el propuesto por las metodologías ágiles, éstas 3 tareas tienden a requerir mayor esfuerzo (HH) a media que pasa el tiempo, ya que cada vez se debe compilar. probar y desplegar una mayor cantidad de código para entregar nuevas funcionalidades y correcciones a la aplicación.

Pero esto no es nada nuevo, ya hemos escuchado del concepto de “Integración Continúa” publicado por Martin Fowler en mayo del 2006, donde ya se habla de la importancia automatizar las pruebas para ganar velocidad en la entrega del software y detectar fallas en etapas tempranas; sin embargo, aún en el 2017 estas prácticas parecen innovadoras y seguimos dudando de la conveniencia de aplicarlas en nuestros proyectos de desarrollo en Chile.

“Nota: los invitamos a leer las mejoras prácticas para integración continua de Martin Fowler: Make Your Build Self-Testing y Test in a Clone of the Production Environment”

En este artículo nos enfocaremos en la automatización de las pruebas, así que por ahora dejaremos de lado la compilación y el despliegue. Entonces, si es recomendable automatizar las pruebas, ¿por qué tanta resistencia a incluir esta práctica en nuestros proyectos ágiles?, Bueno, en un proyecto ágil como Scrum, donde debemos entregar resultados tangibles en poco tiempo o sprints de 2 a 4 semanas, parece una locura dedicar esfuerzos a la automatización de las pruebas, cuando prácticamente no tenemos tiempo ni para el desarrollo. Pero también es una realidad que los Defectos aumentan conforme avanza el proyecto y de acumulan en cada sprint, cuando la teoría dice que deben disminuir eventualmente. Esto es un síntoma de que algo no anda bien, y las causas son las siguientes:

  • Cuando desarrollamos en forma “incremental”, en cada integración debemos probar que todas las funcionalidades críticas de la aplicación sigan funcionando, independientemente de que hayan sido probadas satisfactoriamente en entregas anteriores. Este es el concepto de las Pruebas de Regresión Funcional.
  • Si cada sprint tiene los mismos recursos y duración, no hay tiempo para ejecutar de nuevo las pruebas realizadas en sprints anteriores, así que el equipo de pruebas se enfoca en probar las tareas del sprint actual y asume que todo lo que se probó en sprints anteriores sigue funcionando.

Pero, si tengo que realizar cada vez más pruebas, en el mismo plazo y con los mismos recursos, ¿cuál es la solución?. La solución es mantener los tiempos de ejecución de las pruebas fijos o constantes sin importar la cantidad de pruebas a realizar. Para ello, la clave está en la ejecución automática de las pruebas, ya que mientras una persona puede ejecutar una decena de casos de prueba por día, un robot puede ejecutar cientos de casos de prueba por hora, y además, en horario no laboral. Esta diferencia hace que valga la pena automatizar las pruebas funcionales, siguiendo algunas recomendaciones simples:

  • Planificar tiempos del sprint para la automatización y ejecución de pruebas funcionales.
  • Automatizar pruebas sólo para aquellas funcionalidades críticas y cuyo desarrollo se encuentre estable.
  • Realiza las pruebas manuales de aquellas funcionalidades nuevas y aún no maduras.
  • Seleccionar una herramienta de automatización de pruebas apropiada para la tecnología de desarrollo utilizada en el proyecto.
  • Diseñar una suite de pruebas que permita la ejecución automática de todas las pruebas sin intervención humana, así podría ser ejecutada en forma programada y en horario no laboral.
  • Preparar un ambiente de prueba dedicado al desarrollo y ejecución de pruebas automáticas.
  • Valida la suite de pruebas y define una línea base en la cual confiar para la aceptación o rechazo de la versión recibida por desarrollo.
  • Realizar mantenciones periódicas a los scripts y datos de prueba.
  • Ejecutar una prueba de regresión para cada versión estable del software entregada por Desarrollo. Si la prueba pasa, sigue con las pruebas manuales. Si no pasa, ahorras un valioso tiempo para el equipo de pruebas.
  • Gestiona todos los resultados de las pruebas en una misma herramienta o repositorio, independiente de su ejecución manual o automática. Así podrás gestionar el proceso de QA.
2017-09-04T16:24:27+00:00

Deje su comentario

cinco × 5 =