Cómo hacemos trabajar una Software Factory Agil (III)
En este artículo vamos a hablar cómo realizamos pruebas en Nuestra Software Factory Agil.
Según la metodología Scrum, el mismo equipo Scrum es el que tiene que realizar el desarrollo y las pruebas, las pruebas tienen que venir indicadas cundo se definen las historias de usuario.
Al implantar Scrum en nuestra Factoría de Software, identificamos que el nivel de errores que teníamos en los desarrollos era alto para la calidad y servicio que queríamos proporcionar a nuestros clientes, al final los programadores “saben” lo que han desarrollado y por tanto “saben” lo que tienen que probar, y por tanto no hacen pruebas como poner valores frontera, o probar todos los apartados y posibilidades de su desarrollo.
Eso implicaba retrasos en la entrega final, ya que se tenían errores en las entregas de los Sprints, y esos errores había que planificarlos para solucionarlos en los siguientes Sprints. Y esto terminaba haciendo una pequeña bola de nieve que iba creciendo y terminaba retrasando la entrega final.
Para solucionar este problema, añadimos a nuestro equipo a varias personas especializadas en la realización de pruebas, tanto funcionales, como técnicas.
Y el planteamiento que hicimos y que nos está funcionando perfectamente, es añadir a los equipos Scrum, un Tester, que es el que se encarga de realizar las pruebas del software. Eso hace que los Sprints, que normalmente en nuestro caso eran de dos semanas, han pasado a ser de 3 semanas.
Las dos primeras semanas son de desarrollo, de las funcionalidades, y la segunda y tercera semana se aplican para la realización de las pruebas. La tercera semana, el equipo de desarrollo ya ha comenzado con el siguiente Sprint de desarrollo, mientras que el equipo de pruebas, ejecuta todas las pruebas al software que se va a entregar para asegurarnos de que el trabajo que se va a entregar al cliente está libre de problemas.
Al final, al cliente le añadimos una semana más en la entrega, y lo que generamos son Sprints Independientes de Pruebas desplazados una semana sobre los Sprints de Desarrollo. Esto hace que la primera entrega al cliente tarde una semana más, pero a partir de ahí las entregas se realizan cada dos semanas.
Esta forma de realizar las pruebas en nuestros desarrollos, nos han permitido bajar la tasa de errores de un 14% a menos de un 2%.
Este equipo de pruebas, además en paralelo, trabaja en la automatización de la pruebas más críticas para el negocio, de forma que se puedan lanzar en cualquier momento pruebas de regresión, para ver que los cambios que se han realizado no afectan a lo anteriormente desarrollado.
De hecho, en nuestros proyectos, incluimos Jenkins, para realizar todas las noches un proceso de compilación y ejecución de la batería de pruebas de todos los proyectos que se encuentran en marcha, de forma que por la mañana, al llegar el equipo de programación, se encuentra con un informe de cómo está el desarrollo y de los posibles errores que se han presentado con los cambios del día anterior.
Hemos establecido una metodología que nos ha permitido ser mucho más eficientes en nuestros desarrollos reduciendo los tiempos finales de entrega, y además nos ha posibilitado que el software que desarrollamos tenga mucha más calidad que el que hacíamos al principio de implantar Scrum.
Si necesita implantar Scrum o una metodología ágil en su empresa y necesita ayuda para su implantación, puede contactarnos y nos pondremos en contacto con ustedes para ayudarles a ser mucho más eficiente, ya lo hemos hecho con varios de nuestroc clientes.
Con gusto atenderemos sus necesidades, proporcionándole soluciones y herramientas que le ayuden a crecer su negoci