Entrevista a Francisco Moreno sobre Docker, Cucumber y Selenium
Hace unas semanas celebramos en nuestra sede de Oviedo un KIT sobre Selenium, Cucumber y Docker que impartió nuestro compañero Francisco Moreno. Durante la sesión, los asistentes pudieron aprender cómo realizar la automatización de pruebas web paso a paso y cómo, a partir de las historias de usuario, podemos especificar el test de aceptación de forma clara y concisa para que todos los implicados lo puedan entender.
Hoy hablamos con Francisco Moreno para que nos cuente más detalles sobre su formación sobre Selenium, Cucumber y Docker.
Para aquellos que no lo conozcan: ¿Cómo funcionan Selenium, Cucumber y Docker y por qué recomiendas combinarlos?
Son tres herramientas distintas, cada una de ellas destinada a cumplir un objetivo concreto. Hagamos un breve repaso de todas ellas:
Selenium
Se trata básicamente de un conjunto de librerías que permiten comunicarse con un navegador web mediante un lenguaje de programación. Esto nos permite poder simular las acciones que realizaría un usuario al interactuar con una web tales como: ir a una url determinada, hacer click en un botón, escribir un texto, seleccionar una opción de un desplegable, acciones de arrastre del ratón, subir archivos, etc.
Desde nuestro código podremos recoger los resultados desencadenados por cada una de esas acciones y comprobar que coinciden con los esperados. De esta manera podemos llegar a automatizar las pruebas funcionales de una aplicación web. Web oficial de Selenium.
Cucumber
Es un framework que permite escribir la especificación funcional de un sistema mediante criterios de aceptación utilizando lenguaje de alto nivel, muy similar a cómo nos expresamos las persona de manera natural. Estos se consigue siguiendo las pautas del lenguaje “Gherkin”, que básicamente sigue una estructura de “Given-When-Then” para especificar los criterios de aceptación.
Ejemplo de escenario en lenguaje Gherkin:
Estas especificaciones Gherkin son evaluadas por el framework Cucumber y transformadas en “steps” de bajo nivel en el lenguaje de programación en el que estemos trabajando. Dentro de cada step se deben programar las acciones y asertos adecuados que permitan validar la especificación de manera automática.
La utilización del lenguaje de alto nivel permite que tanto gente más cercana al negocio como la parte técnica compartan un lenguaje común, comprensible por ambos y que ayude a ambas partes a avanzar hacia la construcción de la solución adecuada.
Por tanto, estrictamente hablando, podríamos decir que Cucumber no es un framework de pruebas en sí, si no una herramienta que favorece las conversaciones a la hora de definir requisitos y el desarrollo siguiendo la filosofía BDD (Behaviour Driven Development). Web oficial de Cucumber.
Docker
Se trata en esencia de un gestor de contenedores, una tecnología que lleva existiendo en los sistemas Unix desde hace tiempo.
Trabajar con contenedores nos permite generar “espacios de trabajo” independientes, portables y escalables. Esto resulta de gran importancia para el testing de sistemas, puesto que nos permite contar con sistemas aislados y perfectamente controlados en los que realizar pruebas sin interferencias de otras personas o sistemas.
Además podremos destruir, volver a construir y distribuir los contenedores en un estado concreto de manera que sea más sencillo analizar y reproducir errores. Web oficial de Docker.
¿Cuáles son las principales ventajas de Cucumber frente a otros frameworks para realizar este tipo de pruebas?
Cucumber es un framework open source que lleva entre nosotros más de 10 años. Inicialmente se desarrolló en Ruby y dada su gran aceptación por la comunidad, a día de hoy cuenta con versiones para los lenguajes de programación más utilizados (Java, .Net, Javascipt, Python, PHP, etc..).
Durante estos años no ha dejado de evolucionar y liberar nuevas versiones hasta convertirse en la herramienta de referencia a la hora de abordar enfoques BDD y “Expecification by Example”. Esto hace que exista abundante documentación, ejemplos y tutoriales sobre su uso.
Aunque, sin duda, la principal ventaja de este framework, como he comentado antes, es la de conseguir que la parte técnica y de negocio tengan un punto de unión común que ayude a ambas partes a que en última instancia se construya la solución correcta y adecuada a las especificaciones.
¿Para qué tipo de proyectos recomendarías la automatización de los test de aceptación?
La automatización de pruebas de aceptación resulta interesante en cualquier tipo de proyecto y más aún si se trata de uno donde se sigue una metodología ágil o se tiene previsto realizar entregas continuas en periodos cortos de tiempo.
En estos casos resulta necesario tener una suite de pruebas de regresión que asegure en todo momento que la funcionalidad del sistema no se ha visto comprometida por los cambios introducidos en las nuevas versiones. Es decir, necesitamos un sistema automatizado que nos informe de manera rápida y clara, si alguna funcionalidad previamente entregada contiene algún error. Esto nos va a permitir poder optimizar los esfuerzos en testing y centrar el tiempo de pruebas manuales exploratorias en toda la nueva funcionalidad añadida para asegurar su calidad.
Además, hay que tener en cuenta que a día de hoy la construcción de los sistemas se basa en el uso de APIs, microservicios y sistemas externos, por tanto, intentar abordar la tarea de validar todo el sistema de manera manual resulta casi imposible dentro de unos tiempos razonables.
Durante el KIT, ¿cuáles fueron las principales dudas planteadas por los asistentes?
Se plantearon algunas cuestiones técnicas puntuales, pero creo que las dudas más interesantes surgieron en torno al proceso de definición de dichas pruebas, es decir, ¿cómo, cuándo y quién debe escribir las especificaciones?
Sobre este punto hay varias opiniones y corrientes, pero la idea base se sustenta en que durante la planificación de un sprint o antes de comenzar los desarrollos, se realice la reunión de los “Three amigos”. Estos serían el product owner, desarrollador y tester. Los tres deberán analizar cada historia de usuario y establecer unos criterios de aceptación claros que todos comprendan y no generen dudas.
Estas conversaciones son las que realmente aportan valor a técnicas como BDD o ATDD ya que hacen que todas los involucrados en el proyecto estén alineados en cuanto a la funcionalidad a construir. Además, al participar en este análisis previo un tester que aporte un punto de vista “out of the box” o más crítico, consigue que se detecten posibles problemas en fases tempranas o que se afine mucho más el alcance de cada historia de usuario.
Una vez aclarados estos puntos y por no alargar innecesariamente la reunión de planificación, será el tester o el desarrollador el que escriba los criterios de aceptación acordados en Cucumber para que guíen el desarrollo de la funcionalidad para seguir el enfoque BDD.
¿Qué recomendación le darías a las personas que quieran empezar a automatizar las pruebas de aceptación usando Cucumber, Selenium y Docker?
Mi recomendación principal sería la de que antes comenzar a abordar una solución de este estilo se deben conocer bien las bases de cada herramienta. Esto es, además de conocer su tecnología, ser consciente de sus ventajas, inconvenientes y mejores escenarios de aplicación.
Es decir, estas herramientas pueden ser una ayuda importante en muchos proyectos pero no son una “bala de plata”, en otros muchos casos probablemente no sean la mejor estrategia de construcción de soluciones o de pruebas.
En segundo lugar, una vez “dominada” cada una de las herramientas por separado trataría de comenzar con pruebas de concepto en las que iría añadiendo las diferentes herramientas de manera paulatina. Primero construiría la base para que las pruebas funcionales de Selenium sean mantenibles y fiables. Después haría que estas pruebas se ejecutasen en base a una especificación funcional en Cucumber y finalmente intentaría que dichas pruebas se lanzasen dentro de un contenedor Docker o contra una aplicación desplegada en un contenedor (o la combinación de ambas).
Y por último, mi consejo sería “Try again, fail again, fail better”. Es decir, la automatización de pruebas no es algo sencillo y al construir este tipo de soluciones se introducen capas de complejidad adicionales. Llegar hasta una sistema que funcione correctamente requerirá varias iteraciones, correcciones y refactorizaciones.
¿Quieres aprender a usar Docker, Cucumber y Selenium?
Te contamos más detalles en este curso completo elaborado por Francisco Moreno.
