Cuando de pruebas E2E se trata, la creación de escenarios de alta calidad no solo marca el punto de partida para el diseño de una suite robusta, sino también para documentar de manera clara el funcionamiento a nivel de negocio de una aplicación. Teniendo esto en cuenta, hazte las siguientes preguntas, ¿Cuántos escenarios de prueba con enfoque técnico has construido? ¿Cuántos escenarios de prueba extensos y muy detallados has leído?¿Cuántos escenarios de prueba con muchos elementos que restan legibilidad has visto?. En este artículo, voy a contarte mi experiencia escribiendo escenarios de prueba E2E con alta calidad: legibles, de alto nivel, cortos pero descriptivos y en un lenguaje común de negocio.
Comportamientos: Lo importante
BDD (Desarrollo orientado por comportamientos): Unas siglas que durante los últimos años han sido bastante populares y de las que tanto se habla en las compañías. Pero, ¿qué tiene que ver esto con mis escenarios de prueba?. Bueno… lo que buscamos en un equipo ágil es que todos sus integrantes se comuniquen hablando un idioma común. Ese idioma suele ser el de negocio. Todo el equipo tiene el mismo objetivo: desarrollar software de calidad que satisfaga las necesidades del cliente y por tanto, hablar en términos de negocio resulta siendo la forma mas estratégica de comunicarse. Ahora bien, la relación de todo esto con los escenarios de prueba E2E, es que con ellos buscamos probar procesos de negocio, el uso real que le dará un usuario final a la aplicación. De nuevo, el mejor lenguaje para lograr este objetivo es el de negocio por su simplicidad y su capacidad de unir al equipo a la estrategia de negocio.
Mejorando escenarios — Iteración #1: Escenarios técnicos
Ya que conocemos la importancia de escribir escenarios en lenguaje de negocio, lo último que queremos ver son tecnicismos, ¿verdad?. Veamos el siguiente ejemplo:
Un primer refactor del escenario sería el siguiente:
A esto le conocemos como la conversión de un estilo imperativo a un estilo declarativo. Eliminamos conceptos técnicos que no agregan mayor valor al escenario y como valor agregado obtenemos un escenario más simple y orientado a lo que esperamos de la aplicación en términos de negocio.
Mejorando escenarios — Iteración #2: “Sobreuso” del detalle
Gherkin: Ya que sabemos cuál es el mejor lenguaje a usar para diseñar nuestros escenarios, ¿Cómo hacemos para estructurarlos mejor?. Aquí es donde Gherkin toma protagonismo, ya que define una sintaxis simple para dar estructura a los escenarios. Sin embargo, esta sintaxis tiende a ser usada incorrectamente, debido al frenético deseo de dar demasiado detalle a los escenarios. El punto de cada especificación debería ser el de probar (bajo una perspectiva de alto nivel) el comportamiento de la aplicación desde el punto de vista del usuario final (que no conoce el detalle del funcionamiento de la misma). Entonces… no tiene sentido entregar tanto detalle ¿verdad?.
Volvamos al escenario de la iteración número 1, según la documentación oficial de Cucumber, existen dos “keywords” con un uso estratégico en la narrativa: “And/Y”, “But/Pero” cuya finalidad es la de dar fluidez a los escenarios. Sin embargo, se debe usar con precaución debido a que pueden llevar a escenarios muy detallados, extensos y por ende complejos de leer. Así para nuestro ejemplo, un posible refactor puede ser:
Una razón con mucho peso para evitar el detalle y por ende una gran cantidad de pasos en un escenario es que Cucumber ejecuta cada paso en orden secuencial. Durante la ejecución Cucumber “busca” el ‘step definition’ de ese paso. Recuerda que esa búsqueda tarda en tiempo de ejecución, muy poco pero aumenta el tiempo de ejecución total de la prueba y este problema definitivamente lo queremos evitar. Incluso hay ‘Keywords’ mucho más costosas que otras, por tanto, trata de evitar ambigüedades pero sin caer en el extremo detalle.
Hay que tener en cuenta que cualquier redundancia en las descripciones y palabras también afecta la legibilidad de los escenarios. Teniendo en cuenta esto, podríamos modificar nuestro escenario para que no se refiera al asesor en cada paso, y como resultado, tendríamos algo como lo siguiente.
Si continuamos leyendo el escenario, posiblemente podríamos mejorarlo un poco más. Sin embargo para el ejemplo, es claro que iterando constantemente y redactando de una manera clara el proceso de negocio que se busca probar, lograremos la simplicidad que se requiere.
Recuerda, el detalle técnico nunca es necesario en la redacción del escenario ya que este será descrito en la implementación del mismo.
Mejorando escenarios — Iteración #3: La “obligatoriedad” en la estructura base
Siempre relacionamos Gherkin con exactamente ‘Given-When-Then’. Cada palabra clave tiene una regla de uso que se debe considerar más por buenas prácticas en el uso del lenguaje que por la permisividad en tiempo de ejecución. A permisividad me refiero a que no importa si utilizas el ‘Given’ para validar el estado final del escenario, técnicamente es posible, sin embargo no es una buena práctica. Curiosamente, la estructura base con la que se relaciona Gherkin, no es precisamente una regla. Muchos escenarios son igual de válidos con un ‘When-Then’ por ejemplo.
Según la documentación oficial de Cucumber:
El Given es usado para describir el contexto inicial del sistema, normalmente algo que ya pasó.
Para el escenario en cuestión, el ‘Given’ solo describe el deseo del usuario, es decir que sobra o que no describe lo que realmente se espera que pase dentro del sistema. Entonces el primer refactor podría ser solo eliminar el Given desde que no aporta mayor información al escenario y tal vez mejorar un poco la descripción del escenario para experar bien lo que se quiere hacer:
O, expresar el estado de preparación del sistema (en términos de negocio, claro está).
De que dependerá una decisión u otra. Dependerá del escenario en sí mismo y la correcta implementación que se desarrolle. Es decir, en un ‘step definition’ puedo definir una condición a ejecutar antes de cada test y común a todos los tests. Esta podrá ser abrir la aplicación e incluso crear el cliente aprobado que se requiere para la ejecución de la prueba. O bien, podrá hacer esto en el ‘Given’ según se requiera.
Mejorando escenarios — Iteración #4: Complejidad
En algunas ocasiones, es necesario detallar datos de prueba en el escenario. Si bien hay varias formas de hacerlo, acá quiero presentar una en particular. Con el fin de permitir el reuso de ‘step definitions’, podemos enviar por medio de una tabla, los datos que necesitemos para la ejecución de nuestra prueba, este tipo de tabla se puede crear en cualquier paso que se tenga definido, sin embargo cada paso tiene su responsabilidad y posiblemente no todos sean válidos para tener datos de prueba según el escenario. Una posible implementación de la tabla, para el escenario que venimos trabajando, sería el siguiente:
Una ventaja importante de las tablas es que es posible reusar un ‘step definition’ para ejecutarlo con diferentes datos de prueba. Es importante tener en cuenta que utilizar estas tablas nos facilita el uso de datos de prueba independientes, pero CUIDADO!! … añade un alto nivel de complejidad a nuestro escenario, por esta razón se recomienda no abusar en el tamaño de las tablas. Muchas veces nos encontramos con datos de pruebas con múltiples columnas en las tablas, muchas de ellas completamente innecesarias. Imagina, ¿es necesaria la edad, el nombre de los hijos, la fecha de nacimiento y la escolaridad de la persona en este escenario?. Posiblemente para completar los datos de un crédito si, pero no agrega valor a la descripción del escenario bajo lo que se pretende probar.
La complejidad no solo agrega dificultad en la lectura del escenario, también tiempo de compilación, ejecución y mantenimiento del mismo.
Ahora, imagina que quieres ejecutar una prueba repetidas veces, con el mismo flujo, pero con una datos diferentes. Pues existe un tipo de escenario que combinado con las tablas nos permite realizar este proceso.
Por cada fila que se agregue de datos en la tabla, se realizará una ejecución de todo el escenario. Para este caso aplica la misma advertencia que en el caso anterior, es recomendable ser prudentes con el uso de la tabla. Si se requiere un pool de datos muy grande, es recomendable implementar otra solución.
Algunos tips:
Recordemos que el propósito de los escenarios ademas de describir la prueba que se está ejecutando, es la de servir de documentación de los procesos de la aplicación. Esto quiere decir que van a ser leídos por usuarios, analistas de negocio, equipo técnico y demás interesados. Es por esto que es importante que estén bien redactados, con buena ortografía y en un idioma que sea común en el equipo.
Además, bajo mi experiencia, quiero compartir algunos tips adicionales:
Si usas IntelliJ como IDE de desarrollo, puedes agregar un diccionario para que te ayude con la ortografía en los escenarios, te subrayará en verde las palabras que tengan errores ortográficos.
Siempre puedes contar con la ayuda de alguien más, pide que lean tu escenario y así sabrás si es entendible para el equipo.
Lee tus escenarios más de 2 veces y en voz alta, esto ayuda a identificar posibles correcciones que debas hacer.
Al ejecutar tus pruebas, genera el reporte y analízalo. Suele ser muy útil para identificar posibles mejoras en la reacción, ya que según el tipo de reporte, puede describir el paso a paso (incluyendo el técnico) de cada escenario.
No uses palabras complejas, o lenguaje técnico. Recuerda siempre evitar ambigüedades pero conservando el lenguaje de negocio.
La redacción de los escenarios no solo se debe reducir a una responsabilidad del equipo de calidad. Teniendo en cuenta que desde diferentes perspectivas y especialidades todo el equipo tiene el mismo objetivo de negocio, la responsabilidad se vuelca precisamente a todo el equipo. La importancia de la descripción no se da por capricho o por seguir un manual, se da porque son esos escenarios lo que documentan el estado ideal de la aplicación y cómo ésta responde desde un punto de vista funcional a las interacciones con el cliente. Son esos escenarios los que adicional a eso disminuirán la curva de aprendizaje de cualquier integrante nuevo del equipo y también reducirán la complejidad de agregar nuevos casos de prueba o duplicar casos ya existentes por falta de claridad.
Ahora es tu turno de poner en práctica todo lo que hablamos en este post y animarte a crear escenarios que realmente agreguen valor a la calidad del sistema.
Algunas buenas fuentes adicionales que encontré:
Gracias por leer...
¡Deja tus comentarios y hagamos crecer nuestra comunidad!
