Cucumber no es una herramienta de Testing, es un modelo de colaboración

Principalmente este año y el anterior, hemos estado bastante ocupados ayudando a gente a reforzar sus procesos ágiles con el uso de BDD, Gherkin, Cucumber. Estos temas llevan dando vueltas bastantes años, pero parece que ahora se les está dando su importancia de manera más ámplia. Y, cómo suele suceder, esto suele llevar a algunas interpretaciones no del todo correctas y de ahí viene este post.
Las primeras ideas sobre BDD vienen de hace ya sus años, de allá por 2003, y aunque hoy han sido etiquetadas por muchos como sólo de Testing, deberíamos tener presente que todo esto no sólo es, ni exclusivamente nació, para el Testing: realmente nació para evitar los históricos problemas que conllevan las necesidades de negocio (requisitos, historias, etc.) que se malentienden.
La idea que dio origen a Cucumber era la de combinar las “pruebas de aceptación automatizadas”, los “requisitos funcionales” (historias de usuario, etc.) y la “documentación”, todo ello en un formato entendible (Gherkin) por personas sin conocimientos técnicos (Product Owners, negocio, etc.).
Cuando en 2008 se creó Cucumber, lo hizo para proporcionar ese (a) lenguaje común entendible por personas sin conocimientos técnicos (Gherkin), (b) dar soporte a un proceso (BDD) y (c) ser una herramienta que proporcionaría una fuente única con el comportamiento esperado para el software a desarrollar.
Por ello, el hacer uso de Cucumber es para mucho más que contar con una ayuda para automatizar pruebas. Y esto lo puedes ver claramente en las dos actividades que siempre deben acompañar a Cucumber: los talleres de especificación (tres amigos) y el proceso de “fuera a dentro”.

Los talleres de especificación (tres amigos)

En inglés le llaman así «los tres amigos», en español queda un poco raro, en cualquier caso todo esto viene a que en la definición de una necesidad (requisito, historia, etc.) siempre deben participar “tres amigos”: la persona de negocio, el programador y el Tester. Los tres especifican con ejemplos cómo el software deberá comportarse y lo escriben en escenarios Gherkin.

El proceso: Desarrollo de fuera a dentro, BDD y especificaciones con ejemplos

Al proceso que rodea u engloba a Cucumber Dan North le llamó BDD y Gojko Adzic le dio un otro nombre: Especificación con ejemplos. A todo ello, al proceso, también se le conoce como “desarrollo de fuera a dentro”.
Se llama “de fuera a dentro” porque el desarrollo comienza desde la funcionalidad hacia dentro, hacia el sistema, la funcionalidad guía al desarrollo. Los programadores ejecutan los escenarios que describen cómo se espera que se comporte funcionalmente el sistema con Cucumber, y ello les dice lo qué hay que implementar.
Similar a la idea de TDD, pero Cucumber se sitúa en un nivel de abstracción más alto, más cerca del dominio, del negocio, de las necesidades funcionales y más lejos de clases y métodos.

Cucumber es una herramienta para la colaboración

Cuando Cucumber se usa únicamente como una herramienta para automatizar pruebas y sin la participación de negocio… pierde su valor.
Cuando se escriben los escenarios Gherkin de Cucumber después, una vez que el software está implementado, en vez de al revés, pierdes todas las ventajas.
Las características Cucumber en Gherkin deben escribirse antes que el código de la aplicación. Las características de Cucumber nacen con los requisitos de software. Cucumber es una herramienta de colaboración que busca un entendimiento común de las necesidades, basado en la colaboración de tres roles: negocio, desarrollo y Testing.
 

2 comentarios en “Cucumber no es una herramienta de Testing, es un modelo de colaboración”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba