Code

Behaviour-Driven Development

BDD también se conoce como Especificación por ejemplo.

El Desarrollo Impulsado por el Comportamiento (BDD) es una síntesis y refinamiento de prácticas derivadas del Desarrollo Impulsado por Pruebas (TDD) y el Desarrollo Impulsado por Pruebas de Aceptación (ATDD). BDD aumenta TDD y ATDD con las siguientes tácticas:

  • Aplicar el principio de los “cinco por qué” a cada historia de usuario propuesta, de modo que su propósito esté claramente relacionado con los resultados comerciales.

Cinco por qué, es una técnica interrogativa iterativa utilizada para explorar las relaciones de causa y efecto que subyacen a un problema en particular.

El objetivo principal de la técnica es determinar la causa raíz de un defecto o problema repitiendo la pregunta “¿Por qué?“.

Cada respuesta forma la base de la siguiente pregunta.

El “cinco” en el nombre deriva de una observación anecdótica sobre el número de iteraciones necesarias para resolver el problema.

No todos los problemas tienen una única causa raíz.

Si uno desea descubrir múltiples causas raíz, el método debe repetirse haciendo una secuencia diferente de preguntas cada vez.

El método no proporciona reglas estrictas y rápidas sobre qué líneas de preguntas explorar o cuánto tiempo continuar la búsqueda de causas raíz adicionales.

Por lo tanto, incluso cuando se sigue de cerca el método, el resultado aún depende del conocimiento y la persistencia de las personas involucradas.

https://www.agilealliance.org/glossary/bdd
  • Pensar “de afuera hacia adentro”, en otras palabras, implementar solo aquellos comportamientos que contribuyan más directamente a estos resultados comerciales, a fin de minimizar el desperdicio.
  • Describir comportamientos en una única notación a la que pueden acceder directamente los expertos, probadores y desarrolladores del dominio, para mejorar la comunicación.
  • Aplicar estas técnicas hasta los niveles más bajos de abstracción del software, prestando especial atención a la distribución del comportamiento, para que la evolución siga siendo barata.

Problema: El vehículo no arranca

¿Por quéLa batería está muerta?
¿Por quéEl alternador no funciona?
¿Por quéLa correa del alternador se ha roto?
¿Por quéLa correa del alternador estaba mucho más
allá de su vida útil y no se reemplazó?
¿Por quéEl vehículo no recibió mantenimiento de
acuerdo con el programa de servicio recomendado?

(Quinto por qué, una causa raíz)

El cuestionamiento para este ejemplo podría llevarse a un sexto nivel, séptimo o superior, pero cinco iteraciones de preguntar por qué son generalmente son suficientes para llegar a la causa raíz.

La clave es alentar al solucionador de problemas a evitar suposiciones y trampas lógicas y, en cambio, rastrear la cadena de causalidad en incrementos directos desde el efecto a través de cualquier capa de abstracción hasta una causa raíz que todavía tiene alguna conexión con el problema original.

Tenga en cuenta que, en este ejemplo, el quinto “por qué” sugiere un proceso roto o un comportamiento alterable, que es indicativo de alcanzar el nivel de causa raíz.

La última respuesta apunta a un proceso

Este es uno de los aspectos más importantes del enfoque de los cinco por qué:

La causa raíz real debe apuntar hacia un proceso que no funciona bien o que no existe.

Los facilitadores no capacitados a menudo observarán que las respuestas parecen apuntar hacia respuestas clásicas como falta de tiempo, falta de inversiones o recursos suficientes.

Estas respuestas pueden ser ciertas, pero están fuera de nuestro control.

Por lo tanto, en lugar de preguntarse ¿por qué?, pregunte ¿por qué falló el proceso?.

Historia de usuario

Una historia de usuario es una pequeña pieza de funcionalidad valiosa que se utiliza para planificar y priorizar el trabajo en un equipo ágil.

ronjeffries.com
ronjeffries.com
ronjeffries.com
ronjeffries.com

¿Qué es BDD?

BDD es una forma de trabajar entre los equipos de software, pretende cerrar la brecha entre la gente de negocios y la gente técnica:

  • Fomentando la colaboración entre roles para construir una comprensión compartida del problema a resolver.
  • Trabajando en iteraciones pequeñas y rápidas para aumentar la retroalimentación y el flujo de valor.
  • Produciendo documentación del sistema que se verifica automáticamente contra el comportamiento del sistema.
  • Haciendo esto, enfocados en el trabajo colaborativo, en ejemplos concretos del mundo real que ilustran cómo queremos que se comporte el sistema. Usamos esos ejemplos para guiarnos desde el concepto hasta la implementación, en un proceso de colaboración continua.

BDD y Agile

Vamos a suponer que nuestro equipo ya está utilizando algún tipo de metodología ágil, planificando el trabajo en pequeños incrementos de valor, usando User Stories.

Lo interesante es que BDD no reemplaza el proceso Agile existente, lo mejora.

Pensemos en BDD como un conjunto de complementos para su proceso existente que hará que su equipo sea más capaz de cumplir las promesas de agilidad:

Con lanzamientos oportunos y confiables de software funcional que satisfaga las necesidades cambiantes de la organización, lo que requiere algo de disciplina y esfuerzo de mantenimiento.

Iteraciones rápidas

BDD fomenta el trabajo en iteraciones rápidas, desglosando continuamente los problemas de nuestro usuario en partes pequeñas que pueden fluir a través del proceso de desarrollo lo más rápido posible.

Tres prácticas

Esencialmente, la actividad diaria de BDD es un proceso iterativo de tres pasos:

  • Primero, tome un pequeño cambio próximo al sistema, una historia de usuario, y hable sobre ejemplos concretos de la nueva funcionalidad para explorar, descubrir y acordar los detalles de lo que se espera que se haga.
  • Luego, documente esos ejemplos de una manera que se pueda automatizar y también verificar si están de acuerdo.
  • Finalmente, implemente el comportamiento descrito por cada ejemplo documentado, comenzando con una prueba automatizada para guiar el desarrollo del código.

La idea es hacer que cada cambio sea pequeño para poder iterar rápidamente, volviendo a subir un nivel cada vez que se necesite más información.

Cada vez que automatiza e implementa un nuevo ejemplo, se agrega algo valioso a nuestro sistema, un sistema listo para responder a los comentarios.

Llamamos a estas prácticas:

  • Descubrimiento.
  • Formulación.
  • Automatización.
diagrama de cómo encajan las prácticas
https://cucumber.io/docs/bdd

Con el tiempo, los ejemplos documentados se convierten en un activo que permite a su equipo continuar realizando cambios en el sistema con confianza y rapidez.

El código refleja la documentación, y la documentación refleja la comprensión compartida del equipo sobre el dominio del problema.

Este entendimiento compartido está en constante evolución.

Hay mucho que aprender sobre cada una de estas prácticas. A continuación, resumiremos cada uno de ellas.

Descubrimiento: lo que podría hacer

La parte más difícil de construir un sistema de software es decidir con precisión qué construir.

– Fred Brooks, The mythical man-month.

Aunque la documentación y las pruebas automatizadas son producidas por un equipo de BDD, puede pensar en ellas como buenos efectos secundarios.

El objetivo real es un software valioso y que funcione, y la forma más rápida de lograrlo es a través de conversaciones entre las personas que están involucradas en imaginar y entregar ese software.

Conversaciones

BDD ayuda a los equipos a tener las conversaciones correctas en el momento adecuado, para minimizar la cantidad de tiempo dedicado a las reuniones y maximizar la cantidad de código valioso que produce.

Talleres de descubrimiento

Utilizamos conversaciones estructuradas, llamadas talleres de descubrimiento, que se centran en ejemplos del mundo real del sistema desde la perspectiva de los usuarios.

Estas conversaciones aumentan la comprensión compartida de nuestro equipo sobre las necesidades de nuestros usuarios, las reglas que rigen cómo debe funcionar el sistema y el alcance de lo que se debe hacer.

También puede revelar brechas en nuestra comprensión, donde necesitamos más información antes de saber qué hacer.

El escrutinio de una sesión de descubrimiento a menudo revela una funcionalidad de baja prioridad que se puede diferir del alcance de una historia de usuario, lo que ayuda al equipo a trabajar en incrementos más pequeños y mejora su flujo.

El descubrimiento es el lugar adecuado para comenzar. No se disfrutará mucho de las otras dos prácticas hasta que se haya dominado el descubrimiento.

Formulación: Qué debe hacer

Tan pronto como hayamos identificado al menos un ejemplo valioso de nuestras sesiones de descubrimiento, ahora podemos formular cada ejemplo como documentación estructurada.

Esto nos brinda una forma rápida de confirmar que realmente tenemos una comprensión compartida de qué construir.

A diferencia de la documentación tradicional, utilizamos un medio que puede ser leído tanto por humanos como por computadoras, de modo que:

  • Podemos obtener comentarios de todo el equipo sobre nuestra visión compartida de lo que estamos construyendo.
  • Podremos automatizar estos ejemplos para guiar nuestro desarrollo de la implementación.
  • Al escribir esta especificación ejecutable en colaboración, establecemos un lenguaje compartido para hablar sobre el sistema. Esto nos ayuda a usar la terminología del dominio del problema en todo el código.

Automatización: lo que realmente hace

Ahora que tenemos nuestra especificación ejecutable, podemos usarla para guiar nuestro desarrollo de la implementación.

  • Tomando un ejemplo a la vez, lo automatizamos conectándolo al sistema como prueba.
  • La prueba falla porque aún no hemos implementado el comportamiento que describe.
  • Ahora desarrollamos el código de implementación, utilizando ejemplos de nivel inferior del comportamiento de los componentes internos del sistema para guiarnos según sea necesario.

Los ejemplos automatizados funcionan como guías, ayudándonos a mantener nuestro trabajo de desarrollo encaminado.

Cuando necesitemos regresar y mantener el sistema más tarde, los ejemplos automatizados nos ayudarán a comprender qué está haciendo el sistema actualmente y a realizar cambios de manera segura sin romper nada involuntariamente.

Esta retroalimentación rápida y repetible reduce la carga de las pruebas de regresión manual, liberando a las personas para que realicen un trabajo más interesante, como las pruebas exploratorias.

¿Qué es un taller de descubrimiento?

Un taller de descubrimiento es una conversación en la que personas técnicas y comerciales colaboran para explorar, descubrir y ponerse de acuerdo tanto como puedan sobre el comportamiento deseado para una historia de usuario.

¿Cómo se lleva a cabo un taller de descubrimiento?

Existen varios modelos de talleres de descubrimiento, estos son solo algunos:

Mapeo de ejemplo

Usa un paquete de fichas en cuatro colores diferentes para mapear reglas (un resumen de restricciones/criterios de aceptación que el equipo ha acordado) a ejemplos (ilustraciones/casos de los criterios de aceptación)

Mapeo OOPSI (Resultados, Salidas, Procesos, Escenarios, Entradas)

Similar a Mapeo de ejemplo, utiliza notas Post-it de diferentes colores para mapear procesos/relaciones compartidas entre resultados y escenarios.

Mapeo de funciones

También utiliza Post-it Notes de diferentes colores. El equipo elige una historia del trabajo atrasado, identifica a los actores involucrados, divide la historia en tareas y asigna esas tareas a ejemplos específicos.

¿Cuándo debería realizar un taller de descubrimiento?

Lo más tarde posible, antes de que comience el desarrollo de una nueva historia de usuario, para evitar que se pierdan detalles.

Llevar a cabo un taller de descubrimiento lo más tarde posible también le da al equipo suficiente espacio para cambiar sus planes en caso de que surjan nuevos detalles.

¿Quién debe asistir?

Una buena regla general es de 3 a 6 personas, pero como mínimo deben estar presentes sus tres amigos : un propietario del producto, un desarrollador y un probador.

El propietario de su producto identificará el problema que el equipo debería intentar resolver, el desarrollador abordará cómo crear una solución para dicho problema y el evaluador abordará cualquier caso extremo que pueda surgir.

¿Cuánto dura un taller de descubrimiento?

Idealmente, un taller de descubrimiento debería durar solo entre 25 y 30 minutos por historia.

Si necesita más tiempo, es probable que la historia sea demasiado extensa y deba desglosarse, o que falten algunos detalles.

En el último caso, debe dejar de lado la historia ya que el equipo necesita investigar más.

¿Por qué molestarse?

El propósito de un taller de descubrimiento es brindar a todas las partes interesadas, tanto técnicas como no técnicas, una comprensión compartida del trabajo en cuestión.

Hacerlo fomenta la colaboración interfuncional, un aumento en la retroalimentación y cubre cualquier detalle perdido o suposiciones incorrectas realizadas.

Conclusión

Un taller de descubrimiento es una pieza muy importante del ciclo de vida de BDD, entre otros enfoques de desarrollo Agile.

Sin BDD, seguramente se encontrará con problemas de comunicación y su equipo no descubrirá ninguna incógnita, lo que realmente podría obstaculizar el éxito de su proyecto.