Te va a interesar!

6/recent/ticker-posts

Cucumber: Un mal necesario?



Hace años, muchos años, que automatizo. Muchos de esos años los compartí con lo que es Behaviour Driven Development, BDD de ahora en más. Cucumber y Specflow (su hermanito C#iano) fueron los que más usé, existiendo alguno que otro menos reconocido en el ambiente.

 A priori parece que todo el tema de agregar Features, definir sus pasos en una clase que a su vez invoca funciones de otras clases (siempre que estemos siguiendo el POM o ScreenPlay...lo cuál deberían hacer) y dejar prolijos los hooks y runners son un poco demasiado para lo que tenemos que probar.

Y si! Lo es. De hecho, Cucumber NO es una herramienta de Testing. Es una herramienta de colaboración entre la persona técnica encargada de automatizar y los BA que definen los comportamientos esperados. Si en tu equipo no hay BAs que generen features para que vos definas, qué sentido tiene que estés molestándote con esa integración?                                  

Cuál fue el objetivo de Cucumber y cómo cambió?

Esta herramienta nació justamente de la ambiguedad de la comunicación entre BA  y Testing. Al ser el equipo de Testing el mismo que genera ésto...estamos en el mismo problema que Cucumber trata de resolver. Vuelta al primer casillero hermanos...

Haciendo un poco de historia, ésto comenzó cuando la comunidad de Rails adoptó Cucumber debido a sus necesidades, allá por el 2010. Empezaron a usarlo para escribir casos de prueba, olvidando por completo el objetivo que tenía: La colaboración

En mi experiencia, muchas veces se elige porque es la manera más sencilla de comunicar los resultados a Managers y otros peces gordos, no siempre duchos en los aspectos técnicos de la automatización. Ellos no quieren ver un json siendo validado en el output de consola, quieren ver un Scenario en su idioma, con sus pasos en su idioma, comunicando resultados en...sisi, adivinaron, su idioma.

Pero he aquí un problema: El que define los pasos y Scenarios es el Test Engineer. Esto es análogo (quizás en menor medida) al Dev tomándose libertades creativas con el documento técnico. Y de ahí generamos todo tipo de deuda técnica y confusiones, porque esos Scenarios y Steps no están siendo validados por la persona que debería. Muchas veces vi forzar esos pasos para ajustarse a que el test ande. O que los steps no estén correctamente segmentados...

Mi pregunta siempre no es si necesitamos Cucumber, es: Tenemos a un BA que nos genere los Features que tenemos que definir? Si la respuesta es "no", mi propuesta es siempre no molestarse y tomar el camino de, por ejemplo, TestNG.

Está en la habilidad del Tester el poder proveer un reporte o output amigable para las personas no técnicas, ya sea en un mail, jenkins, bamboo o donde los jefes miren los resultados.

Por supuesto que lo ideal, la utopía, es tener a los BAs al menos revisando los Features que generamos nosotros o, en el mejor de los mejores casos, generando ellos estos tests, pero muchas veces ésto no es posible por diversos motivos. Quizás compartimos proyectos con otras empresas no tan abiertas a colaborar, a pesar de que DevOps hoy en día es TODO ACERCA DE COLABORAR. Quizás no le den la importancia suficiente a la tarea y no quieran revisar los Features generados por testing...hay mil motivos, pero es importante poder adaptarse a ésto.

Y ustedes, qué experiencia tienen con Cucumber? Lo encuentran útil? Lo usan como su creador lo querría? Cuenten sus opiniones en los comentarios!

Publicar un comentario

1 Comentarios

  1. Interesante, sospecho que muchos no le dan el uso adecuado. Pero yo intentaré hacerlo

    ResponderBorrar