Te va a interesar!

6/recent/ticker-posts

Qué es BDD?


Seguramente, más de una vez en sus vidas de testers o búsquedas laborales, habrán leído las siglas BDD. Que Cucumber es para BDD, que hacemos BDD en este proyecto... pero qué es?

En este post voy a contarles qué es y por qué casi nadie lo usa realmente! 

Cuál es la definición de BDD?

La definición oficial es Behavior Driven Development. Esto qué significa? Significa que vamos a tener especificaciones escritas en un lenguaje no técnico y entendible para cualquiera que lo lea, sobre qué se espera de la funcionalidad de la aplicación, desde la perspectiva de los tests que van a probar que funcionen bien. 

Para ser más claro: Vamos a escribir como una funcionalidad debería comportarse en un lenguaje no técnico. Esto se llama, dependiendo la herramienta que se use: Feature.

Para qué sirve?

Este proceso, devenido de otro llamado TDD (Test Driven Development que vamos a ver en otro post), fue creado con el propósito de que haya colaboración entre Developers, Business Analysts y Test Engineers.

La story que el BA crea es fácilmente creada como Feature, con su implementación detrás de escena. Ese test, creado en herramientas como Specflow o Cucumber, dice fuerte y claro qué es lo que hace, por lo que el BA puede entenderlo perfectamente, sugerir cambios, etc.

Para qué se usa generalmente?

En la realidad, nos encontramos conque se usa Cucumber porque a alguien se le ocurrió y no porque realmente se esté haciendo BDD. A veces, ni siquiera hay un BA chequeando los features creados, salidos de la imaginación del Tester sin ningún tipo de Peer Review. 

Esto nos lleva a tener una capa más de complejidad innecesaria ya que no se le da uso. Si, algunos podrán argumentar que los resultados de Cucumber son más entendibles para un Manager que los que te pueda arrojar un TestNG, pero la realidad es que el propósito de Cucumber es otro! 

Cómo logramos darle el uso que se espera?

Si estás en un proyecto en el que se usa Cucumber u otra herramienta de BDD y sentís que no se está haciendo como la definición oficial dicta, hay varias cosas que podés hacer: 
  • Involucrar a los responsables de los diseños funcionales o stories en revisar los tests creados en BDD.
  • Involucrar a los desarrolladores para que den luz verde a la cobertura que se le dio a la funcionalidad en los tests creados en BDD.
  • Si por algún motivo no podés hacer ninguna de las dos anteriores, involucrar a tu Test Lead o Manager en el signoff de lo creado.
Con esto vamos a lograr que no seamos los únicos artífices de esos tests. En mis años de experiencia, he visto multitud de veces el uso de Cucumber solo por usarlo. A veces los steps no tenían nada que ver con lo que se hacía realmente en sus definiciones... en fin, todo se distorsionaba horriblemente.

Después algo fallaba, todos se preguntaban: Pero por qué pasó esto si el test lo cubría? Para descubrir que el test estaba haciendo algo completamente diferente. 

O a veces se hacen Features con un lenguaje técnico que no aporta nada y termina echándose a perder la oportunidad de hacer BDD correctamente!

Herramientas de BDD más conocidas.


Cucumber:


Si hablamos de las herramientas de BDD más conocidas, creo que todos vamos a estar de acuerdo en que Cucumber es la más popular hoy en día. La magia de Cucumber es que cuenta con una comunidad enorme, plugins y un sinfín de implementaciones en distintos Frameworks. 
Como lenguaje usa Gherkin, que es un DSL con el famoso Given, When, Then. 

Es open source, lo que quizás explique parte de su popularidad! También se integra fácil a herramientas de CI/CD como Jenkins, Bamboo y Travis. 

Permite parametrizar pasos en nuestros scenarios, serializarlos con tablas de ejemplos, configurar pasos como prerequisitos y mucho más! Si quieren aprender cómo crear un Framework desde cero con Cucumber, les recomiendo pasar por mis tutoriales

Concordion:


Este la verdad que no lo conocía hasta que... uno de sus desarrolladores fue mi jefe y me mostró cómo funciona. Debo decir que no soy un gran fan (recuerdo que le dije eso para su sorpresa) pero entiendo que es una herramienta muy potente. 

En este caso vamos a trabajar sobre un HTML, lo que nos permite tener especificaciones "vivas" como dicen ellos. La documentación, corriendo como tests... todo en uno. Algo parecido ponele a lo que hace Google Colab con sus documentos (sin la parte de correr todo en la nube!). 

Lo que no me gustó fue que requería que todos los que la usen sepan de HTML. Osea, si le pedías a un BA que te genere los scenarios en esta herramienta para que vos puedas implementarlo en automation (descontando copypastear), el BA necesita saber usar HTML, markup y demás para que quede todo bien. Me pareció algo prohibitivo al divino botón y una cosa que va en contra de la colaboración que tiene que ser BDD.

Se integra con JUnit, por lo que pueden enchufarlo a cualquier framework con Gradle o Maven y Java que estén usando! 

JBehave:


Si, Java saltó a hacer su propia herramienta para BDD y creó JBehave. Al igual que las dos anteriores, es open source y aborda la misma idea: Escribir los tests en un lenguaje humano para luego implementar las definiciones de cada paso en nuestra lógica en código.

En este caso, adivinaron, es puro Java. Nada muy especial que mencionar sobre esta herramienta porque, en lo personal, no la he usado.


Fitnesse:


Una herramienta con sus buenos años encima y que no me gusta ni un poco. Suele ser elegida porque brinda una suerte de codeless para la implementación de los pasos. Aunque si hay que escribir código, no es más que un DSL que ellos mismos implementaron y que, en lo personal, se me hizo confuso y con muchas falencias para trabajar en proyectos grandes.

Ventajas? Te genera una wiki en la que corres los tests. Si, en teoría suena lindo, pero en la práctica las cosas no son tan lindas... Desde el debugging cuando algo falla, a la implementación de un Page Object Model coherente, todo es bastante entreverado. Plus... no creo que nadie te lo pida hoy en día para un puesto de trabajo. 

Decir que también, detrás de bambalinas, trabaja con Selenium y Java, aunque viene ya todo implementado para que podamos empezar a usarlo.

Specflow:


El Cucumber de Shelbyville. Es la versión para C# de Cucumber! De sus mismos creadores. No hay nada diferente al pasar de uno al otro.

Especialmente recomendado si van a trabajar con toda la suite .NET! 

Conclusión.

No hay nada más lindo que cuando trabajamos en un equipo colaborativo en el que tenemos esta simbiosis entre devs, QAs y BAs! Es en el momento en que uno entiende la verdadera fortaleza de este proceso llamado BDD: La gente. Si, como siempre les digo, las herramientas están para ayudar a la gente, no para traer problemas. Como con todo lo relacionado a la ingeniería de software, el corazón de todo está siempre en la gente detrás. Un equipo no es BDD por usar Cucumber, de la misma manera que no es DevOps por usar Jenkins (posta, lo escuché una vez). 

Publicar un comentario

0 Comentarios