menu_superior

Automatización de Pruebas (y IV): Caso de Éxito

Este post forma parte de una serie, si quieres acceder a las entradas anteriores, aquí tienes la primera, aquí la segunda y aquí la tercera.

Para abordar este último post de la serie me voy a tomar la licencia de prescindir de detalles que permitan identificar al cliente por que no afectan al mensaje que quiero transmitir y alguien puede tener la impresión que estoy divulgando información “sensible”. La importancia y donde quiero poner el acento es en el aporte de valor añadido de un sistema de pruebas automatizadas  acortando el ciclo de salida a producción y liberando componentes del equipo de una tarea repetitiva y, por lo tanto, aburrida.

Veamos.

Originalmente tenemos un sistema que recibe cada tres semanas una nueva versión incorporando tanto evolutivos como correctivos desarrollados en los días anteriores. Como la importancia del sistema es total ya que soporta al negocio y hay funcionalidades que son absolutamente criticas para el uso del mismo se establece como requisito que en la salida a producción se haga un ciclo de pruebas sobre el conjunto de funcionalidades criticas.

Hasta aquí todo perfecto, el planteamiento del cliente es impecable y sobre el papel tenemos varios filtros que reducen los errores que pueden paralizar la actividad a la mínima expresión. Eso sí, afrontemos el hecho de que el requisito de probar las funcionalidades criticas obliga a dedicar una parte de nuestros escasos recursos a ejecutar estas pruebas y a reportar los resultados. Y esto SI es un problema por que implica que dos personas estén durante una jornada y media cada una (tres jornadas en total) dedicadas exclusivamente a este tema.

Desde nuestra posición era evidente que, de ser posible una solución automatizada, el ahorro que aportaría absorbería rapidamente los costes de desarrollar los aproximadamente 100 scripts que validaban las funcionalidades. Nuestra estrategia tenía dos fases:

  1. Asegurar la viabilidad técnica. No era fácil construir los scripts ya que el entorno tecnológico era muy complejo y había que implicar a distintos departamentos de áreas diferentes. Gracias a la buena voluntad, el buen ambiente y, por qué no decirlo, la curiosidad por ver qué era aquello de la automatización… Conseguimos montar un entorno, grabar y ejecutar los scripts correctamente y cerciorarnos que era posible ejecutar pruebas automáticas que asegurasen el buen funcionamiento de las funcionalidades críticas.
  2. Ejecutar un piloto. Siempre que tengamos una solución tenemos que ser capaces de transmitir qué problemas es capaz de resolver o a qué problemas nos estamos anticipando. Hay que vender la solución. En este caso lo teníamos fácil por que ya estábamos dentro del cliente y era relativamente fácil demostrar su funcionamiento y el tiempo que le iba a ahorrar este planteamiento. No obstante no conviene “vender la piel del oso antes de cazarlo” y hay que invertir tiempo en ver la solución desde el punto de vista del cliente.

Cuando el cliente vio los scripts funcionando, rápidamente llegó a la conclusión que era posible sustituir a los miembros de su equipo por un puñado de scripts y nos dio via libre para automatizar la totalidad de las funcionalidades críticas.

Desde entonces, y después de un periodo de ejecución supervisada, las pruebas se ejecutan de manera automática y desatendida en menos de dos horas: se programa la ejecución de los scripts cuando está disponible la versión correspondiente de la aplicación, se lanzan los scripts y se reciben los informes que sirven de base para evaluar la salida a producción.

Como podéis ver hemos eliminado el riesgo del error humano por repetir las mismas pruebas una y otra vez, hemos ahorrado tiempo de puesta en producción (de 3 jornadas a 2 horas) y hemos liberado a miembros del equipo que ahora pueden dedicarse a otra cosa mientras supervisan que no se detectan errores en la ejecución de las pruebas.

, , , ,