Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Agile Testing y el Sprint +1

3 comments
Agile Testing y el Sprint +1

La regla del Sprint +1.

Recientemente pude tener acceso a un documento de HP en el que se hablaba sobre el enfoque del Testing en equipos ágiles.

Aunque de manera sucinta – el informe pone el foco en la automatización de las pruebas, terreno en el que HP dispone una tremenda herramienta ( por su tamaño y capacidades) como es Hp-Unified functional Testing, antes llamada QTP –  lo cierto es que el informe no menciona para nada la herramienta en sí.

Lo que me interesó y llamó la atención del citado informe es el concepto que en él subyace :  la regla de automatización del Sprint+1.

Trataré de resumirlo en estas líneas, pero el informe lo explica claramente y en mi opinión merece la pena leerlo.

Ágil, tiene entre otras muchas cosas buenas, que el descubrimiento de problemas se realiza de manera temprana, al contrario que en Waterfall en donde la validación del software se produce en las últimas etapas del proyecto.

Con los modelos ágiles, el código que desarrolla el equipo es potencialmente desplegable en los entornos de producción, por lo que es crítico que esté 100% probado y no solamente el código que resuelve las características comprometidas en el Sprint, sino que también debe realizarse la prueba de todo lo que ya ha subido en los Sprints anteriores, para evitar de esta manera, que algo ya implantado pueda dejar de funcionar como consecuencia de la entrada de nuevo código.

Dado que la funcionalidad evoluciona en cada entrega , las pruebas que hagamos también deben ir evolucionando, aumentando el espectro de las mismas para que contemplen tanto lo nuevo como lo que ya se ha entregado.

Partiendo de la base de que automatizarlo todo es imposible, debido al coste de dicha automatización y su mantenimiento posterior, casi tan costoso o más que la propia creacion de los Scripts, deberíamos por tanto centrar nuestros esfuerzos de automatización de pruebas en las funcionalidades core, esto es, en aquellas que tengan un mayor grado de utilización por parte de nuestros usuarios o clientes.

El informe propone que nos centremos en las siguientes cuestiones para decidir que automatizar :

– Las funcionalidades críticas de la aplicación ( ya mencionado).

– Las funcionalidades que pudieran estar afectadas por un SLA.

– Las conexiones o interfaces con otros sistemas.

– Las funcionalidades que en caso de fallo puedan representar impactos económicos.

Lo anterior, no quiere decir que solo se tengan que automatizar las pruebas en los proyectos que se enfocan en ambientes ágiles. Las pruebas de regresión automatizadas son una buena y necesaria práctica en cualquier modelo de desarrollo que empleemos. Los Scripts de pruebas han de ir avanzando una vez que el proyecto ha sido implantado y entramos en fase de mantenimiento. Sin embargo, si aplicamos un modelo ágil en nuestro proyecto, estas pruebas automaticas tienen que surgir antes. Nuestra estrategia de despliegue basada en iteraciones  asi lo aconseja, para mantener la calidad de manera continua a lo largo de todas las entregas o Sprints, en las que el producto, aúnque no es completo, si que es  funcional según lo establecido en nuestro Road-Map.

La automatización de pruebas en ambientes ágiles, definida en el informe como la regla del Sprint+1, consiste básicamente en que tras la implantación de las funcionalidades del Sprint X, en el Sprint X+1, una de las tareas del Sprint Backlog debe ser la creación de los Scripts de pruebas de regresión automatizados de las funcionalidades que se hayan implantado en el Sprint X.

No entro en el articulo en cuestiones organizativas del proyecto respecto a donde reside la función de Testing y quien debe ser el que las planifique y realice, pues eso dependerá de cada organización y de cada proyecto.

Se da por sentado que en el Sprint X todo lo que se haya integrado y desplegado ha pasado por todos los tipos de pruebas posibles, unitarias, exploratorias, funcionales, de interfaz de usuario, etc, y que por tanto lo que vamos buscando con las pruebas de Sprint+1 es aumentar nuestra sensación de tranquilidad a medida que el proyecto va avanzando. En otro caso, podríamos encontrar problemas funcionales ocultos , o de estabilidad en momentos próximos al fin del proyecto, durante las últimas iteraciones.

En definitiva, un informe interesante por el concepto de Agile Testing y Sprint X+1 que me apetecía compartir con vosotros.

Os dejo algunos enlaces de interés sobre herramientas de pruebas de software

globetesting.com/2012/03/comparativa-de-herramientas-para-pruebas-automaticas/

pmoinformatica.com/2012/11/5-herramientas-para-la-automatizacion.html

testeandosoftware.com/las-mejores-herramientas-para-realizar-pruebas-de-software/

¿Alguno de vosotros ha implementado este enfoque?. ¿Qué herramienta habéis empleado para ello?

  1. Muy buen artículo. No me importaría tratar de poner este enfoque en practica, pero la ‘experiencia agile’ duró unos cuantos meses en mi empresa, después de los cuales se decidió volver al modo K.OS. (léase caos).

    Espero poder probarlo en el futuro.

    Un saludo.

    • Pepe Vázquez says:

      Muchas gracias Raúl, me alegra que te guste y ya no me alegra tanto que tuvierais que volver a los usos antiguos ;). Estaría muy bien,si crees que es posible, comentarlo saber cuales son las razones que hicieron adoptar Agile luego abandonarlo. Como experiencia para compartir y aprender. ¿Te animas?. Otra vez gracias.

      • Claro, te cuento brevemente. Tras un tiempo a la deriva, en el que no había ningún método de trabajo, ni procesos ni nada, y tras un brevísimo intento de Kamban, entro un nuevo desarrollador que era Scrum Master, y de los buenos. Por parte de desarrollo / test la experiencia creo que era muy muy buena, pero al parecer “negocio” no tenía la visibilidad que necesitaba. A esto se añadía que no había interés en compartir ciertos conocimientos, y que todo desarollador conociera todo el código, sino que había grupos, casi clases. Además, el día que se planeaba el siguiente sprint salías del scrum meeting con n tareas, y al día siguiente ya se habían añadido n más, con lo que era posible cumplir los compromisos. Finalmente y, tras quemar al scrum master, se volvió al caos anterior.

        Para mi, como tester, la etapa scrum fue muy positiva. Quizás este enfoque del Sprint +1 nos habría venido bien.

        Un cordial saludo.

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*